【Richtlinien】Überlegungen zur Einführung von AWS IAM / AWS IAM Identity Center in Unternehmensorganisationen/-systemen

📅 Erstellt: 2023/08/07, Aktualisiert: 2025/05/05 ⏱️ Geschätzte Lesezeit ~9 mins (1,637 Wörter)

AWS IAM Identity Center is a service for centrally managing authentication and authorization of users and applications in a multi-account environment.
In contrast, AWS IAM is a service for managing authentication and authorization of users and applications within a single AWS account.This article provides an overview of AWS IAM / AWS IAM Identity Center and describes key points to check when considering their introduction to your corporate organization or system.

Inhaltsverzeichnis

Revision History
What is AWS IAM?
What is AWS IAM Identity Center?
Considerations for Adoption
1. 1. What is the contract type of your AWS account?
Design Considerations
Related Documents

Revision History

Date	Update Details
2025/05/05	Added “③ Definition of IAM Permission Design Policy” to “Design Considerations”

What is AWS IAM?

AWS IAM (hereafter, “IAM”) is a service for managing access to AWS resources.
With IAM, you can create users, groups, and roles, and grant these entities permissions to control access to AWS resources.
IAM is an essential service for using AWS. You can create “IAM users” for operating the AWS Management Console and “IAM roles” for granting access permissions to AWS resources.
However, if you use AWS IAM Identity Center as described below, you can operate without creating IAM users.
When using IAM users, you need to issue credentials for access via the AWS CLI or SDK, but with AWS IAM Identity Center, issuing credentials is not necessary.
Issuing credentials for IAM users requires regular updates, increasing management overhead. There is also a risk of misuse if credentials are leaked.
With AWS IAM Identity Center, you do not need to issue credentials. You can obtain temporary credentials via the AWS Access Portal or when executing AWS CLI commands.

What is AWS IAM Identity Center?

AWS IAM Identity Center (hereafter, “IIC”) is a service for identity and access management in multi-account AWS environments.
It provides an AWS Access Portal for unified management of access to AWS resources, offering links for accessing the management console of each AWS account.
Access permissions are managed in units called “permission sets,” which define access rights to AWS accounts.
You can also obtain temporary credentials for each AWS account, which can be used to operate AWS resources via the AWS CLI or SDK.
By integrating with external identity providers (IdPs), you can sign in to the access portal using existing credentials. As of July 30, 2023, the following IdPs are supported:
Azure AD
CyberArk
Google Workspace
JumpCloud
Okta
OneLogin
Ping Identity

Considerations for Adoption

1. What is the contract type of your AWS account?

If you have a multi-account structure, it is recommended to use IIC, Okta, Entra ID, or another IDaaS that can manage access to multiple accounts. IIC automatically distributes IAM roles to each AWS account, reducing operational overhead compared to IDaaS.
IIC is enabled in the management account. It is important to check the contract type of your AWS account and whether management account features are available.
For details on contract types, see Guidelines: Considerations for Introducing AWS Organizations to Corporate Structure/Systems | Moderniser.repo .

Design Considerations

1. Organizing the Stakeholders

When designing IAM, it is important to clarify the roles of stakeholders within the organization.
Referring to Best Practices for Standardizing AWS Usage Guidelines | Amazon Web Services Blog , I have organized the definitions in my own way.
The four roles—CCoE, common platform administrator, security personnel, and accounting/finance—may be handled by the same department or person depending on the organization.

No	Role	Description	Responsibilities
01	CCoE	Center for promoting and operating cloud adoption	Developing guidelines
02	Common Platform Admin	Provides cross-system common platforms and functions in the cloud	Building and operating the common platform
03	Security	Maintains security in the cloud environment	Defining security policies, building and operating security functions, security monitoring and operations
04	System Administrator	Builds and operates systems running in the cloud	Building and operating AWS resources, system construction and operation
05	Operations	Operations management in the cloud environment	System monitoring and operation
06	Accounting/Finance	Allocation and optimization of AWS usage costs	Reviewing cost allocation policies, considering purchase options, cost monitoring, payment of AWS usage fees

2. Role Assignment Organization (Determining the Scope and Method of IAM Permission Delegation)

Decide how much IAM management authority should be delegated to system administrators, and what methods or restrictions should be applied if delegation is performed.
The elements managed in IAM are: “IAM User,” “IAM Group,” “IAM Role,” and “IAM Policy.”
While it is possible for the common platform administrator to manage everything, as the system grows, management costs increase, so consider delegating IAM management authority to users.
Generally, consider using SCP (Service Control Policy) to prohibit specific operations at the account level as the primary method for delegation to system administrators.
Here are six typical use cases.

Use Case 1: Delegate management permissions except for IAM users/groups

Requirement Item	Details
Use of AWS Organizations (SCP) or IIC	✓ Available
Delegation of user management	✗ Cannot be delegated to system
Delegation of role/policy management	✓ Can be delegated to system

One effective internal fraud countermeasure is the removal of unnecessary users.
Users who have access to AWS accounts must regularly review and remove unnecessary users.
To prevent omissions in user deletion, user management should be performed by the common platform administrator, not delegated to system administrators.
To prevent improper configuration of IAM role trust policies, consider using Access Analyzer for detection.

Use Case 2: Delegate management permissions except for IAM users/groups using Permissions Boundary

Requirement Item	Details
Use of AWS Organizations (SCP) or IIC	✗ Not available
Delegation of user management	✓ Can be delegated to system
Delegation of role/policy management	✓ Can be delegated to system

If management account features are not available, you can delegate to system administrators by restricting the permissions that can be granted to IAM roles using Permissions Boundary.

Use Case 3: Create a system-dedicated bastion account and delegate all IAM management permissions

Requirement Item	Details
Use of AWS Organizations (SCP) or IIC	✓/✗ Available / Not available
Delegation of user management	✓ Can be delegated to system
Delegation of role/policy management	✓ Can be delegated to system

When delegating IAM user management permissions to system administrators, you can also create a bastion account centrally managed by the system administrator.

Use Case 4: Delegate IAM management permissions except for IAM groups

Requirement Item	Details
Use of AWS Organizations (SCP) or IIC	✗ Not available
Delegation of user management	✓ Can be delegated to system
Delegation of role/policy management	✓ Can be delegated to system

IAM groups are managed by the common platform administrator, and system administrators grant permissions to IAM users by assigning them to IAM groups.
Since IAM user permissions are controlled by the common platform administrator, this prevents system administrators from granting unauthorized permissions.
This also reduces the workload for permission design.

Use Case 5: Do not delegate any IAM management permissions

Requirement Item	Details
Use of AWS Organizations (SCP) or IIC	✓/✗ Available / Not available
Delegation of user management	✗ Cannot be delegated to system
Delegation of role/policy management	✗ Cannot be delegated to system

By having the common platform administrator retain all IAM management permissions, you can choose not to delegate to system administrators.
Since IAM users and roles must be created based on requests from system administrators, management costs may increase.

3. Defining the IAM Permission Design Policy

One of the main challenges in designing IAM permissions is determining how strictly to apply the principle of least privilege.
As a best practice, it is recommended to grant IAM users and IAM roles only the minimum permissions necessary.
However, restricting permissions for IAM users and roles may increase the operational burden on system administrators.
Therefore, it is important to assess the business risks associated with the granted IAM permissions in advance and grant permissions within an acceptable risk range.
In addition to IAM permission controls, using AWS Organizations’ SCP (Service Control Policy) can help reduce the burden of IAM permission design.
Properly segmenting AWS accounts is also important. By dividing AWS accounts, even if IAM permissions are inappropriately granted, the impact can be limited.
There are three types of policies you can use to grant IAM permissions:
Inline policies
AWS managed policies
Customer managed policies
Of these, “AWS managed policies” are provided by AWS and are offered after AWS has properly evaluated the permissions. By using these policies, you can grant write and read permissions for each AWS service.
Basically, it is recommended to use AWS managed policies. However, since AWS managed policies may grant excessive permissions, consider using “customer managed policies” or “inline policies” to further restrict permissions as needed.
For example, in the following patterns, consider using “customer managed policies” or “inline policies” to restrict permissions.

Pattern 1: Granting management permissions for KMS keys

To grant management permissions for KMS keys using AWS managed policies, you can use the AWS managed policy “AWSKeyManagementServicePowerUser.”
Reference: AWSKeyManagementServicePowerUser - AWS Managed Policy
However, using this policy grants powerful permissions for KMS keys, such as creating or deleting keys and changing IAM policies.
Therefore, consider using IAM policies to grant permissions only for specific KMS keys.
For example, the following IAM policy grants permission to decrypt data encrypted with KMS keys that have a specific tag:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "kms:Decrypt",
                   "kms:GenerateDataKey"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/System": "SystemA"
                }
            }
        }
    ]
}

Pattern 2: Granting Execution Permissions for SSM Automation / Lambda / Step Functions, etc.

When granting execution permissions for AWS resources such as Lambda or Step Functions, you are granting the permissions that are exercised when those resources are executed.
If executing these resources poses a business risk, consider restricting execution permissions using IAM policies.
For example, by using the following IAM policy, you can grant permission to execute Lambda functions that follow a specific naming convention.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:ap-northeast-1:123456789012:function:SystemA-*"
            ]
        }
    ]
}

Pattern 3: Assuming IAM Roles in External Accounts

When you need to assume an IAM role in an external account, you can grant the AssumeRole permission using an IAM policy.
This cannot be granted using AWS managed policies, so you must use a custom IAM policy to grant the permission.
For example, the following IAM policy grants permission to assume specific IAM roles.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::123456789012:role/SystemA-*"
            ]
        }
    ]
}

Pattern 4: When Data Administrators and Users Differ

When using data stores such as S3 or DynamoDB, the data administrator and user may be different.
For example, if the administrator of an S3 bucket is different, you can use IAM policies to grant permissions to specific S3 bucket administrators.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "s3:PutObject",
                   "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::systema-bucket",
                "arn:aws:s3:::systema-bucket/*"
            ]
        }
    ]
}