기업 조직/시스템에 AWS IAM/AWS IAM Identity Center를 도입하기 위한 【지침】 고려 사항

📅 작성일: 2023/08/07, 수정일: 2025/05/05 ⏱️ 예상 읽기 시간 약 13분 (5,108자)

AWS IAM Identity Center는 다중 계정 환경에서 사용자 및 애플리케이션의 인증 및 권한을 중앙에서 관리하는 서비스입니다.
반면 AWS IAM은 단일 AWS 계정 내에서 사용자 및 애플리케이션의 인증 및 권한을 관리하는 서비스입니다.이 문서에서는 AWS IAM/AWS IAM Identity Center에 대한 개요를 제공하고 기업 조직 또는 시스템에 대한 소개를 고려할 때 확인해야 할 핵심 사항을 설명합니다.

개정 내역
AWS IAM이란 무엇입니까?
AWS IAM 자격 증명 센터란 무엇입니까?
채택 시 고려 사항
1. 1. AWS 계정의 계약 유형은 무엇입니까?
디자인 고려 사항
관련 문서

개정 내역

날짜	업데이트 세부정보
2025/05/05	“설계 고려 사항”에 “3IAM 권한 설계 정책 정의”를 추가했습니다.

AWS IAM이란 무엇입니까?

AWS IAM(이하 “IAM”)은 AWS 리소스에 대한 접근을 관리하는 서비스입니다.
IAM을 사용하면 사용자, 그룹 및 역할을 생성하고 이러한 엔터티에 AWS 리소스에 대한 액세스를 제어할 수 있는 권한을 부여할 수 있습니다.
IAM은 AWS를 사용하는데 꼭 필요한 서비스입니다.AWS Management Console을 운영하기 위한 “IAM 사용자”와 AWS 리소스에 대한 액세스 권한을 부여하기 위한 “IAM 역할”을 생성할 수 있습니다.
단, 아래 설명과 같이 AWS IAM Identity Center를 사용하면 IAM 사용자를 생성하지 않고도 운영이 가능합니다.
IAM 사용자를 사용할 경우 AWS CLI 또는 SDK를 통해 액세스하려면 자격 증명을 발급해야 하지만, AWS IAM Identity Center에서는 자격 증명을 발급할 필요가 없습니다.
IAM 사용자에 대한 자격 증명을 발급하려면 정기적인 업데이트가 필요하므로 관리 오버헤드가 증가합니다.자격 증명이 유출되면 오용의 위험도 있습니다.
AWS IAM Identity Center를 사용하면 자격 증명을 발급할 필요가 없습니다.AWS Access Portal을 통해 또는 AWS CLI 명령을 실행할 때 임시 자격 증명을 얻을 수 있습니다.

AWS IAM 자격 증명 센터란 무엇입니까?

AWS IAM Identity Center(이하 “IIC”)는 다중 계정 AWS 환경에서 ID 및 액세스 관리를 위한 서비스입니다.
AWS 리소스에 대한 액세스를 통합 관리하기 위한 AWS 액세스 포털을 제공하며, 각 AWS 계정의 관리 콘솔에 액세스할 수 있는 링크를 제공합니다.
액세스 권한은 AWS 계정에 대한 액세스 권한을 정의하는 “권한 세트”라는 단위로 관리됩니다.
AWS CLI 또는 SDK를 통해 AWS 리소스를 운영하는 데 사용할 수 있는 각 AWS 계정에 대한 임시 자격 증명을 얻을 수도 있습니다.
외부 ID 공급자(IdP)와 통합하면 기존 자격 증명을 사용하여 액세스 포털에 로그인할 수 있습니다.2023년 7월 30일 현재 다음 IdP가 지원됩니다.
Azure AD
사이버아크
구글 워크스페이스
점프클라우드
옥타
원로그인
핑 아이덴티티

채택 시 고려 사항

1. AWS 계정의 계약 유형은 무엇입니까?

다중 계정 구조를 가지고 있는 경우, 다중 계정에 대한 접근을 관리할 수 있는 IIC, Okta, Entra ID 또는 기타 IDaaS를 사용하는 것이 좋습니다.IIC는 IAM 역할을 각 AWS 계정에 자동으로 배포하여 IDaaS에 비해 운영 오버헤드를 줄입니다.
IIC는 마스터 계정에서 활성화됩니다.AWS 계정의 계약 유형과 마스터 계정 기능을 사용할 수 있는지 확인하는 것이 중요합니다.
계약 유형에 대한 자세한 내용은 지침: AWS 조직을 기업 구조/시스템에 도입하기 위한 고려 사항 |Moderniser.repo .

디자인 고려 사항

1. 이해관계자 구성

IAM을 설계할 때 조직 내 이해관계자의 역할을 명확히 하는 것이 중요합니다.
AWS 사용 지침 표준화 모범 사례 |Amazon Web Services 블로그 에서 정의를 저만의 방식으로 정리했습니다.
CCoE, 공통 플랫폼 관리자, 보안 담당자, 회계/재무 등 4가지 역할은 조직에 따라 동일한 부서 또는 담당자가 처리할 수 있습니다.

아니요	역할	설명	책임
01	CCoE	클라우드 도입 촉진 및 운영 센터	지침 개발
02	공통 플랫폼 관리자	클라우드에서 시스템 간 공통 플랫폼 및 기능 제공	공통 플랫폼 구축 및 운영
03	보안	클라우드 환경의 보안을 유지합니다.	보안 정책 정의, 보안 기능 구축 및 운영, 보안 모니터링 및 운영
04	시스템 관리자	클라우드에서 실행되는 시스템 구축 및 운영	AWS 리소스 구축 및 운영, 시스템 구축 및 운영
05	운영	클라우드 환경에서의 운영 관리	시스템 모니터링 및 운영
06	회계/재무	AWS 사용 비용 할당 및 최적화	비용 할당 정책 검토, 구매 옵션 고려, 비용 모니터링, AWS 사용료 지불

2. 역할 부여 조직(IAM 권한 위임 범위 및 방법 결정)

시스템 관리자에게 IAM 관리 권한을 어느 정도 위임해야 하는지, 위임할 경우 어떤 방식이나 제한 사항을 적용할지를 결정합니다.
IAM에서 관리하는 요소는 ‘IAM 사용자’, ‘IAM 그룹’, ‘IAM 역할’, ’IAM 정책’이다.
공통 플랫폼 관리자가 모든 것을 관리하는 것도 가능하지만, 시스템이 커지면 관리 비용도 늘어나므로 IAM 관리 권한을 사용자에게 위임하는 것을 고려해 보세요.
일반적으로 시스템 관리자에게 위임하는 기본 방법으로 계정 수준에서 특정 작업을 금지하는 SCP(서비스 제어 정책)를 사용하는 것을 고려합니다.
다음은 6가지 일반적인 사용 사례입니다.

사용 사례 1: IAM 사용자/그룹을 제외한 관리 권한 위임

요구사항 항목	세부
AWS Organizations(SCP) 또는 IIC 사용	✓ 가능
사용자 관리 위임	✗ 시스템에 위임할 수 없습니다.
역할/정책 관리 위임	✓ 시스템에 위임 가능

효과적인 내부 사기 대책 중 하나는 불필요한 사용자를 제거하는 것입니다.
AWS 계정에 접근할 수 있는 사용자는 불필요한 사용자를 정기적으로 검토하고 제거해야 합니다.
사용자 삭제 누락을 방지하기 위해 사용자 관리는 시스템 관리자에게 위임하지 않고 공통 플랫폼 관리자가 수행해야 합니다.
IAM 역할 신뢰 정책의 부적절한 구성을 방지하려면 탐지를 위해 Access Analyser를 사용하는 것이 좋습니다.

사용 사례 2: 권한 경계를 사용하여 IAM 사용자/그룹을 제외한 관리 권한 위임

요구사항 항목	세부
AWS Organizations(SCP) 또는 IIC 사용	✗ 사용할 수 없음
사용자 관리 위임	✓ 시스템에 위임 가능
역할/정책 관리 위임	✓ 시스템에 위임 가능

마스터 계정 기능을 사용할 수 없는 경우 권한 경계를 사용하여 IAM 역할에 부여할 수 있는 권한을 제한하여 시스템 관리자에게 위임할 수 있습니다.

사용 사례 3: 시스템 전용 배스천 계정을 생성하고 모든 IAM 관리 권한을 위임합니다.

요구사항 항목	세부
AWS Organizations(SCP) 또는 IIC 사용	✓/✗ 가능 / 불가
사용자 관리 위임	✓ 시스템에 위임 가능
역할/정책 관리 위임	✓ 시스템에 위임 가능

IAM 사용자 관리 권한을 시스템 관리자에게 위임할 때, 시스템 관리자가 중앙에서 관리하는 배스천 계정을 생성할 수도 있습니다.

사용 사례 4: IAM 그룹을 제외한 IAM 관리 권한 위임

요구사항 항목	세부
AWS Organizations(SCP) 또는 IIC 사용	✗ 사용할 수 없음
사용자 관리 위임	✓ 시스템에 위임 가능
역할/정책 관리 위임	✓ 시스템에 위임 가능

IAM 그룹은 공통 플랫폼 관리자가 관리하며, 시스템 관리자는 IAM 사용자를 IAM 그룹에 할당하여 권한을 부여합니다.
IAM 사용자 권한은 공통 플랫폼 관리자가 제어하므로 시스템 관리자가 승인되지 않은 권한을 부여하는 것을 방지합니다.
권한 설계에 대한 작업량도 줄어듭니다.

사용 사례 5: IAM 관리 권한을 위임하지 마세요.

요구사항 항목	세부
AWS Organizations(SCP) 또는 IIC 사용	✓/✗ 가능 / 불가
사용자 관리 위임	✗ 시스템에 위임할 수 없습니다.
역할/정책 관리 위임	✗ 시스템에 위임할 수 없습니다.

공통 플랫폼 관리자가 모든 IAM 관리 권한을 보유하게 함으로써 시스템 관리자에게 위임하지 않도록 선택할 수 있습니다.
IAM 사용자 및 역할은 시스템 관리자의 요청에 따라 생성되어야 하므로 관리 비용이 증가할 수 있습니다.

3. IAM 권한 설계 정책 정의

IAM 권한을 설계할 때 주요 과제 중 하나는 최소 권한 원칙을 얼마나 엄격하게 적용할지 결정하는 것입니다.
모범 사례로서 IAM 사용자 및 IAM 역할에 필요한 최소한의 권한만 부여하는 것이 좋습니다.
단, IAM 사용자 및 역할에 대한 권한을 제한하면 시스템 관리자의 운영 부담이 가중될 수 있습니다.
따라서 IAM 권한 부여와 관련된 비즈니스 위험을 사전에 평가하여 허용 가능한 위험 범위 내에서 권한을 부여하는 것이 중요합니다.
IAM 권한 제어 외에도 AWS Organizations의 SCP(서비스 제어 정책)를 사용하면 IAM 권한 설계 부담을 줄이는 데 도움이 될 수 있습니다.
AWS 계정을 적절하게 분할하는 것도 중요합니다.AWS 계정을 분할하면 IAM 권한이 부적절하게 부여되더라도 영향이 제한될 수 있습니다.
IAM 권한을 부여하는 데 사용할 수 있는 세 가지 유형의 정책이 있습니다.
인라인 정책
AWS 관리형 정책
고객 관리형 정책
이 중 “AWS 관리형 정책”은 AWS에서 제공하며, AWS가 권한을 적절하게 평가한 후 제공됩니다.이러한 정책을 사용하면 각 AWS 서비스에 대한 쓰기 및 읽기 권한을 부여할 수 있습니다.
기본적으로 AWS 관리형 정책을 사용하는 것을 권장합니다.그러나 AWS 관리형 정책은 과도한 권한을 부여할 수 있으므로 “고객 관리형 정책” 또는 “인라인 정책”을 사용하여 필요에 따라 권한을 추가로 제한하는 것이 좋습니다.
예를 들어, 다음 패턴에서는 ‘고객 관리형 정책’ 또는 ’인라인 정책’을 사용하여 권한을 제한하는 것을 고려해보세요.

패턴 1: KMS 키에 대한 관리 권한 부여

AWS 관리형 정책을 사용하여 KMS 키에 대한 관리 권한을 부여하려면 AWS 관리형 정책 “AWSKeyManagementServicePowerUser”를 사용하면 됩니다.
참조: AWSKeyManagementServicePowerUser - AWS 관리형 정책
그러나 이 정책을 사용하면 키 생성 또는 삭제, IAM 정책 변경 등 KMS 키에 대한 강력한 권한이 부여됩니다.
따라서 특정 KMS 키에 대해서만 권한을 부여하려면 IAM 정책을 사용하는 것이 좋습니다.
예를 들어 다음 IAM 정책은 특정 태그가 있는 KMS 키로 암호화된 데이터를 해독할 수 있는 권한을 부여합니다.

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

패턴 2: SSM 자동화/Lambda/Step Functions 등에 대한 실행 권한 부여

Lambda 또는 Step Functions와 같은 AWS 리소스에 대한 실행 권한을 부여하면 해당 리소스가 실행될 때 실행되는 권한을 부여하게 됩니다.
이러한 리소스를 실행하면 비즈니스 위험이 발생할 경우 IAM 정책을 사용하여 실행 권한을 제한하는 것이 좋습니다.
예를 들어 다음 IAM 정책을 사용하면 특정 명명 규칙을 따르는 Lambda 함수를 실행할 수 있는 권한을 부여할 수 있습니다.

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

패턴 3: 외부 계정에서 IAM 역할 가정

외부 계정에서 IAM 역할을 수임해야 하는 경우 IAM 정책을 사용하여 AssumeRole 권한을 부여할 수 있습니다.
AWS 관리형 정책으로는 권한을 부여할 수 없으므로, 사용자 지정 IAM 정책을 사용해 권한을 부여해야 합니다.
예를 들어 다음 IAM 정책은 특정 IAM 역할을 맡을 수 있는 권한을 부여합니다.

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

패턴 4: 데이터 관리자와 사용자가 다른 경우

S3, DynamoDB 등 데이터 스토어 이용 시 데이터 관리자와 사용자가 다를 수 있습니다.
예를 들어 S3 버킷의 관리자가 다른 경우 IAM 정책을 사용하여 특정 S3 버킷 관리자에게 권한을 부여할 수 있습니다.

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