# IAM이란 무엇입니까?
AWS Identity and Access Management(IAM)은 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스입니다. IAM을 사용하면 사용자가 액세스할 수 있는 AWS 리소스를 제어하는 권한을 관리할 수 있습니다. IAM을 사용하여 리소스를 사용하도록 인증(로그인) 및 권한 부여(권한 있음)된 대상을 제어합니다. IAM은 AWS 계정에 대한 인증 및 권한 부여를 제어하는 데 필요한 인프라를 제공합니다.
**ID**
AWS 계정을 생성하는 경우에는 모든 AWS 서비스 서비스와 리소스에 대한 완전한 액세스 권한이 있는 AWS 계정 *루트 사용자*라는 단일 로그인 ID로 시작합니다. 일상적인 태스크에 루트 사용자를 사용하지 않을 것을 강력히 권장합니다. 루트 사용자 자격 증명이 필요한 작업은 *IAM 사용자 설명서*의 [루트 사용자 자격 증명이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) 섹션을 참조하세요.
IAM을 사용하여 루트 사용자 외에 관리자, 분석가, 개발자 등 다른 ID를 설정하고 작업을 성공적으로 수행하는 데 필요한 리소스에 대한 액세스 권한을 부여할 수 있습니다.
**액세스 관리**
IAM에 설정된 사용자는 로그인 자격 증명을 사용하여 AWS에 인증합니다. AWS 계정에서 신뢰하는 보안 주체(IAM 사용자, AWS STS 페더레이션 보안 주체, IAM 역할 또는 애플리케이션)와 로그인 보안 인증 정보를 일치시키는 방식으로 인증이 제공됩니다. 다음으로 보안 주체에게 리소스 액세스 권한을 부여하도록 요청이 이루어집니다. 사용자에게 리소스에 대한 권한이 부여된 경우 권한 부여 요청에 대한 응답으로 액세스 권한이 부여됩니다. 예를 들어, 콘솔에 처음 로그인하고 콘솔 홈 페이지에 있는 경우에는 특정 서비스에 액세스하고 있지 않습니다. 서비스를 선택하면 인증 요청이 해당 서비스로 전송되어 인증된 사용자 목록에 ID가 있는지, 부여된 액세스 수준을 제어하기 위해 어떤 정책이 적용되고 있는지, 적용될 수 있는 기타 정책이 있는지 확인합니다. AWS 계정 내의 보안 주체나 신뢰할 수 있는 AWS 계정을 통하여 인증을 요청할 수 있습니다.
인증된 후에는 보안 주체가 AWS 계정에서 리소스에 조치를 취하거나 작업을 수행할 수 있습니다. 예를 들어, 보안 주체는 새 Amazon Elastic Compute Cloud 인스턴스를 시작하거나, IAM 그룹 멤버십을 수정하거나, Amazon Simple Storage Service 버킷을 삭제할 수 있습니다.
**작은 정보**
AWS Training and Certification에서 IAM에 대한 10분 소개 동영상을 제공합니다.
[AWS Identity and Access Management 소개](https://www.aws.training/learningobject/video?id=16448)
**서비스 가용성**
IAM은 다른 많은 AWS 서비스처럼 [최종 일관성](https://wikipedia.org/wiki/Eventual_consistency)이 있습니다. IAM은 전 세계 Amazon 데이터 센터 내의 여러 서버로 데이터를 복제함으로써 고가용성을 구현합니다. 일부 데이터를 변경하겠다는 요청이 성공하면 변경이 실행되고 그 결과는 안전하게 저장됩니다. 그러나 변경 사항은 IAM 전체에 복제되어야 하고, 이 작업에는 어느 정도 시간이 소요됩니다. 그러한 변경 사항에는 사용자, 그룹, 역할 또는 정책을 만들거나 업데이트한 것이 포함됩니다. 그러한 IAM 변경 사항을 애플리케이션의 중요한 고가용성 코드 경로에 포함시키지 않는 것이 좋습니다. 대신 자주 실행하지 않는 별도의 초기화 루틴이나 설정 루틴에서 IAM을 변경하세요. 또한 프로덕션 워크플로우에서 변경 사항을 적용하기 전에 변경 사항이 전파되었는지 확인하세요. 자세한 내용은 [변경 사항이 매번 즉시 표시되는 것은 아닙니다](troubleshoot.md#troubleshoot_general_eventual-consistency) 섹션을 참조하세요.
**서비스 비용 정보**
AWS Identity and Access Management(IAM), AWS IAM Identity Center, AWS Security Token Service(AWS STS)는 추가 비용 없이 AWS 계정에 제공되는 기능입니다. IAM 사용자 또는 AWS STS 임시 보안 자격 증명을 사용하여 다른 AWS 서비스에 액세스하는 경우에만 요금이 부과됩니다.
IAM Access Analyzer 외부 액세스 분석은 추가 비용 없이 제공됩니다. 하지만 사용하지 않은 액세스 분석 및 고객 정책 확인에는 요금이 발생합니다. IAM Access Analyzer에 관련된 전체적인 요금 및 가격 목록은 [IAM Access Analyzer 요금](https://aws.amazon.com/iam/access-analyzer/pricing)을 참조하세요.
다른 AWS 제품 요금에 대한 자세한 내용은 [Amazon Web Services 요금 페이지](https://aws.amazon.com/pricing/)를 참조하세요.
**다른 AWS 서비스와의 통합**
IAM은 많은 AWS 서비스와 통합되어 있습니다. IAM과 함께 사용할 수 있는 AWS 서비스 목록과 해당 서비스가 지원하는 IAM 기능은 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md) 섹션을 참조하세요.
# 왜 IAM을 사용해야 하나요?
AWS Identity and Access Management는 AWS 리소스에 대한 액세스를 안전하게 관리하기 위한 강력한 도구입니다. IAM을 사용하여 얻을 수 있는 주요 이점 중 하나는 AWS 계정에 공유 액세스 권한을 부여할 수 있다는 것입니다. 또한 IAM을 사용하면 세분화된 권한을 할당할 수 있으므로 각 사용자가 특정 리소스에서 수행할 수 있는 작업을 정확히 제어할 수 있습니다. 이러한 수준의 액세스 제어는 AWS 환경의 보안을 유지하는 데 매우 중요합니다. IAM은 몇 가지 다른 보안 기능도 제공합니다. 추가 보호 계층을 위해 다중 인증(MFA)을 추가하고 ID 페더레이션을 활용하여 기업 네트워크 또는 다른 ID 공급자의 사용자를 원활하게 통합할 수 있습니다. 또한 IAM은 AWS CloudTrail과 통합되어 감사 및 규정 준수 요구 사항을 지원하는 상세한 로깅 및 ID 정보를 제공합니다. 이러한 기능을 활용하면 중요한 AWS 리소스에 대한 액세스를 엄격하게 제어하고 안전하게 보호할 수 있습니다.
## AWS 계정에 대한 공유 액세스
암호나 액세스 키를 공유하지 않고도 AWS 계정의 리소스를 관리하고 사용할 수 있는 권한을 다른 사람에게 부여할 수 있습니다.
## 세분화된 권한
리소스에 따라 여러 사람에게 다양한 권한을 부여할 수 있습니다. 예를 들어 일부 사용자에게 Amazon Elastic Compute Cloud(Amazon EC2), Amazon Simple Storage Service(Amazon S3), Amazon DynamoDB, Amazon Redshift 및 기타 AWS 서비스에 대한 완전한 액세스를 허용할 수 있습니다. 다른 사용자에게는 일부 Amazon S3 버킷에 대한 읽기 전용 권한, 일부 Amazon EC2 인스턴스를 관리할 수 있는 권한 또는 결제 정보에만 액세스할 수 있는 권한을 허용할 수 있습니다.
## Amazon EC2에서 실행되는 애플리케이션을 위한 보안 AWS 리소스 액세스
EC2 인스턴스에서 실행되는 애플리케이션의 경우 IAM 기능을 사용하여 자격 증명을 안전하게 제공할 수 있습니다. 이러한 자격 증명은 애플리케이션에 다른 AWS 리소스에 액세스할 수 있는 권한을 제공합니다. 예를 들면 이러한 리소스에는 S3 버킷 및 DynamoDB 테이블이 있습니다.
## 다중 인증(MFA)
보안 강화를 위해 계정과 개별 사용자에게 2팩터 인증을 추가할 수 있습니다. MFA를 사용할 경우 계정 소유자나 사용자가 계정 작업을 위해 암호나 액세스 키뿐 아니라 특별히 구성된 디바이스의 코드도 제공해야 합니다. 이미 다른 서비스와 함께 FIDO 보안 키를 사용하고 있으며 FIDO 보안 키의 구성에 AWS가 지원되는 경우 MFA 보안을 위해 WebAutn을 사용할 수 있습니다. 자세한 내용은 [패스키 및 보안 키 사용이 지원되는 구성](id_credentials_mfa_fido_supported_configurations)을 참조하세요.
## 아이덴티티 페더레이션
기업 네트워크나 인터넷 ID 공급자와 같은 다른 곳에 이미 암호가 있는 사용자에게 AWS 계정에 대한 액세스를 허용할 수 있습니다. 이러한 사용자에게는 IAM 모범 사례 권장 사항을 준수하는 임시 자격 증명이 부여됩니다. ID 페더레이션을 사용하면 AWS 계정 보안이 강화됩니다.
## 보장을 위한 자격 증명 정보
[AWS CloudTrail](https://aws.amazon.com/cloudtrail/)을 사용하는 경우 계정의 리소스를 요청한 사람에 대한 정보가 포함된 로그 레코드를 받게 됩니다. 이 정보는 IAM 자격 증명을 기반으로 합니다.
## PCI DSS 준수
IAM에서는 판매자 또는 서비스 공급자에 의한 신용카드 데이터의 처리, 저장 및 전송을 지원하며, Payment Card Industry(PCI) Data Security Standard(DSS) 준수를 검증받았습니다. AWS PCI 규정 준수 패키지의 사본을 요청하는 방법 등 PCI DSS에 대해 자세히 알아보려면 [PCI DSS 레벨 1](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/)을 참조하세요.
# IAM을 사용하는 경우
AWS Identity and Access Management은 AWS 내의 ID에 따라 액세스 제어의 기반을 제공하는 핵심 인프라 서비스입니다. AWS 계정에 액세스할 때마다 IAM을 사용합니다. IAM을 사용하는 방법은 조직 내의 특정 책임과 직무에 따라 달라집니다. AWS 서비스 사용자는 IAM을 사용하여 일상 업무에 필요한 AWS 리소스에 액세스하고 관리자는 적절한 권한을 부여합니다. 반면 IAM 관리자는 IAM ID를 관리하고 리소스에 대한 액세스를 제어하는 정책을 작성할 책임이 있습니다. 역할과 관계없이 AWS 리소스에 대한 액세스를 인증하고 권한을 부여할 때마다 IAM과 상호 작용하게 됩니다. 여기에는 IAM 사용자로 로그인하거나, IAM 역할을 수임하거나, 원활한 액세스를 위해 ID 페더레이션을 활용하는 것이 포함될 수 있습니다. AWS 환경에 대한 보안 액세스를 효과적으로 관리하려면 다양한 IAM 기능과 사용 사례를 이해하는 것이 중요합니다. 정책 및 권한 생성과 관련하여 IAM은 유연하고 세분화된 접근 방식을 제공합니다. 사용자 또는 역할이 액세스할 수 있는 작업 및 리소스를 지정하는 자격 증명 기반 정책 외에 역할을 수임할 수 있는 보안 주체를 제어하는 신뢰 정책을 정의할 수 있습니다. 이러한 IAM 정책을 구성하면 사용자와 애플리케이션이 필요한 작업을 수행할 수 있는 적절한 수준의 권한을 갖도록 할 수 있습니다.
## 다른 직무를 수행하는 경우
AWS Identity and Access Management은 AWS 내의 ID에 따라 액세스 제어의 기반을 제공하는 핵심 인프라 서비스입니다. AWS 계정에 액세스할 때마다 IAM을 사용합니다.
IAM를 사용하는 방법은 AWS에서 수행하는 작업에 따라 달라집니다.
+ 서비스 사용자 - AWS 서비스를 사용하여 작업을 수행하는 경우 필요한 자격 증명과 권한을 관리자가 제공합니다. 더 많은 고급 기능을 사용하여 작업을 수행하게 되면 추가 권한이 필요할 수 있습니다. 액세스 권한 관리 방법을 이해하면 관리자에게 올바른 권한을 요청하는 데 도움이 됩니다.
+ 서비스 관리자 - 회사에서 AWS 리소스를 책임지고 있는 경우 IAM에 대한 전체 액세스 권한을 가지고 있을 것입니다. 서비스 관리자는 서비스 사용자가 액세스해야 하는 IAM 기능과 리소스를 결정합니다. 그런 다음 IAM 관리자에게 요청을 제출하여 서비스 사용자의 권한을 변경해야 합니다. 이 페이지의 정보를 검토하여 IAM의 기본 개념을 이해하세요.
+ IAM 관리자 - IAM 관리자인 경우 IAM 자격 증명을 관리하고 IAM에 대한 액세스 권한을 관리하는 정책을 작성할 수 있습니다.
## AWS 리소스에 액세스할 권한이 있는 경우
인증은 ID 자격 증명을 사용하여 AWS에 로그인하는 방식입니다. AWS 계정 루트 사용자이나 IAM 사용자로, 또는 IAM 역할을 수임하여 인증(에 로그인)받아야 합니다.
AWS IAM Identity Center(IAM Identity Center), Single Sign-On 인증 또는 Google/Facebook 자격 증명과 같은 자격 증명 소스의 자격 증명을 사용하여 페더레이션 ID로 로그인할 수 있습니다. 로그인하는 방법에 대한 자세한 내용은 *AWS Sign-In사용 설명서*의 [AWS 계정에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 섹션을 참조하세요.
프로그래밍 방식 액세스를 위해 AWS는 요청에 암호화 방식으로 서명할 수 있는 SDK 및 CLI를 제공합니다. 자세한 내용은 *IAM 사용 설명서*의 [API 요청용 AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) 섹션을 참조하세요.
## IAM 사용자로 로그인하는 경우
*[IAM 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*는 단일 개인 또는 애플리케이션에 대한 특정 권한을 가진 ID입니다. 장기 자격 증명이 있는 IAM 사용자 대신 임시 자격 증명을 사용하는 것이 좋습니다. 자세한 내용은 *IAM 사용 설명서*에서 [임시 자격 증명을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 제공업체와의 페더레이션을 사용하도록 요구](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)를 참조하세요.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)은 IAM 사용자 모음을 지정하고 대규모 사용자 집합에 대한 관리 권한을 더 쉽게 만듭니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM 사용자 사용 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) 섹션을 참조하세요.
## IAM 역할을 맡을 경우
*[IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*은 임시 자격 증명을 제공하는 특정 권한이 있는 자격 증명입니다. [사용자에서 IAM 역할(콘솔)로 전환](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)하거나 AWS CLI 또는 AWS API 작업을 직접적으로 호출하여 역할을 수임할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [역할 수임 방법](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)을 참조하세요.
IAM 역할은 페더레이션 사용자 액세스, 임시 IAM 사용자 권한, 교차 계정 액세스, 교차 서비스 액세스 및 Amazon EC2에서 실행되는 애플리케이션에 유용합니다. 자세한 내용은 *IAM 사용 설명서*의 [교차 계정 리소스 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)를 참조하세요.
## 정책 및 권한을 생성하는 경우
사용자에게 권한을 부여하려면 사용자가 수행할 수 있는 작업과 그러한 작업으로 인해 영향을 받을 수 있는 리소스를 나열하는 문서에 해당하는 정책을 만들어야 합니다. 명시적으로 허용되지 않은 작업 또는 리소스는 기본적으로 모두 거부됩니다. 정책을 생성하여 보안 주체(사용자, 사용자 그룹, 사용자가 맡는 역할, 리소스)에 연결할 수 있습니다.
다음 정책은 IAM 역할과 함께 사용할 수 있습니다.
+ **신뢰 정책** – 역할을 수임할 수 있는 [보안 주체](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#principal)와 역할 수임 조건을 정의합니다. 신뢰 정책은 IAM 역할에 대해 특정한 유형의 리소스 기반 정책 유형입니다. 역할은 하나의 신뢰 정책만 가질 수 있습니다.
+ **자격 증명 기반 정책(인라인 및 관리형)** – 이러한 정책은 해당 역할의 사용자가 수행할 수 있는 (또는 수행할 수 없도록 거부되는) 권한과 리소스 위치를 정의합니다.
[IAM 자격 증명 기반 정책의 예](access_policies_examples.md) 사용 시 IAM 자격 증명에 대한 권한을 정의하는 데 유용할 수 있습니다. 필요로 하는 정책을 찾은 다음에 View this policy(이 정책 보기)를 선택하여 정책의 JSON을 확인합니다. JSON 정책 문서를 자체 정책의 템플릿으로 활용할 수 있습니다.
**참고**
IAM Identity Center를 사용하여 사용자를 관리하는 경우 권한 정책을 보안 주체에 연결하는 대신 IAM Identity Center에서 권한 세트를 할당합니다. 그룹 또는 AWS IAM Identity Center의 사용자에 권한 세트를 할당하면 IAM Identity Center가 각 계정에 해당되는 IAM 역할을 생성하고 권한 세트에 지정된 정책을 해당 역할에 연결합니다. IAM Identity Center는 역할을 관리하고, 정의에 따라 인증된 사용자가 역할을 맡을 수 있도록 합니다. 권한 세트를 수정하면 IAM Identity Center에서 해당 IAM 정책 및 역할이 그에 따라 업데이트되도록 합니다.
IAM Identity Center에 대한 자세한 내용은 *AWS IAM Identity Center 사용 설명서*의 [ What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)(IAM Identity Center란 무엇인가요?) 섹션을 참조하세요.
# IAM 관리 방법
AWS 환경 내에서 AWS Identity and Access Management를 관리하려면 다양한 도구와 인터페이스를 활용해야 합니다. 가장 일반적인 방법은 사용자 및 역할 생성부터 권한 구성에 이르기까지 광범위한 IAM 관리 작업을 수행할 수 있는 웹 기반 인터페이스인 AWS Management Console을 사용하는 것입니다.
명령줄 인터페이스에 더 익숙한 사용자를 위해 AWS는 두 가지 명령줄 도구 세트(AWS Command Line Interface 및 AWS Tools for Windows PowerShell)를 제공합니다. 이를 통해 터미널에서 직접 IAM 관련 명령을 실행할 수 있으며, 이는 콘솔을 탐색하는 것보다 훨씬 효율적입니다. 또한 AWS CloudShell은 콘솔 로그인과 관련된 권한을 사용하여 웹 브라우저에서 직접 CLI 또는 SDK 명령을 실행할 수 있습니다.
콘솔과 명령줄 외에도 AWS는 다양한 프로그래밍 언어를 위한 소프트웨어 개발 키트(SDK)를 제공하므로 IAM 관리 기능을 애플리케이션에 직접 통합할 수 있습니다. 또는 서비스로 직접 HTTPS 요청을 실행할 수 있는 IAM 쿼리 API를 사용하여 프로그래밍 방식으로 IAM에 액세스할 수 있습니다. 이러한 다양한 관리 접근 방식을 활용하면 IAM을 기존 워크플로 및 프로세스에 유연하게 통합할 수 있습니다.
## AWS Management Console 사용
AWS Management Console은 AWS 리소스 관리를 위한 다양한 서비스 콘솔의 모음을 구성하고 참조하는 웹 애플리케이션입니다. 처음 로그인하면 콘솔 홈 페이지가 나타납니다. 홈 페이지는 각 서비스 콘솔에 대한 액세스를 제공하며, 이 단일 위치에서 AWS 관련 작업을 수행하는 데 필요한 정보에 액세스할 수 있습니다. 콘솔에 로그인한 후 사용할 수 있는 서비스와 애플리케이션은 액세스 권한이 있는 AWS 리소스에 따라 달라집니다. 역할을 수임하거나 권한이 부여된 그룹의 멤버가 되거나 명시적으로 권한을 받아 리소스에 대한 권한을 부여받을 수 있습니다. 독립 실행형 AWS 계정의 경우 루트 사용자 또는 IAM 관리자가 리소스에 대한 액세스를 구성합니다. AWS Organizations의 경우 관리 계정 또는 위임된 관리자가 리소스에 대한 액세스를 구성합니다.
AWS Management Console을 사용하여 AWS 리소스를 관리하게 하려면 보안 [모범 사례](best-practices.md)로 임시 보안 인증 정보를 사용하여 사용자를 구성하는 것이 좋습니다. 역할을 수임한 IAM 사용자, 페더레이션 보안 주체 및 IAM Identity Center의 사용자는 임시 자격 증명을 보유하고, IAM 사용자와 루트 사용자는 장기 자격 증명을 보유합니다. 루트 사용자 보안 인증은 AWS 계정에 대한 전체 액세스 권한을 제공하는 반면, 다른 사용자는 IAM 정책에서 부여한 리소스에 대한 액세스 권한을 제공하는 보안 인증을 보유합니다.
로그인 환경은 AWS Management Console 사용자 유형마다 다릅니다.
+ IAM 사용자와 루트 사용자는 기본 AWS 로그인 URL(https://signin.aws.amazon.com)에서 로그인합니다. 로그인한 후에 권한이 부여된 계정의 리소스에 액세스할 수 있습니다.
루트 사용자로 로그인하려면 루트 사용자 이메일 주소와 암호가 있어야 합니다.
IAM 사용자로 로그인하려면 AWS 계정 번호나 별칭, IAM 사용자 이름 및 IAM 사용자 암호가 있어야 합니다.
계정의 IAM 사용자를 장기 보안 인증이 필요한 특정 상황(예: 긴급 액세스)으로 제한하고 [루트 사용자 보안 인증이 필요한 작업](id_root-user.md#root-user-tasks)에만 루트 사용자를 사용하는 것이 좋습니다.
사용자 편의를 위해 AWS 로그인 페이지는 브라우저 쿠키를 사용하여 IAM 사용자 이름 및 계정 정보를 기억합니다. 다음에 사용자가 AWS Management Console의 아무 페이지로든 이동하면 콘솔이 쿠키를 사용하여 사용자를 사용자 로그인 페이지로 리디렉션합니다.
세션이 끝나면 콘솔에서 로그아웃하여 이전 로그인을 다시 사용하지 않도록 합니다.
+ IAM Identity Center 사용자는 조직에 고유한 특정 AWS 액세스 포털을 사용하여 로그인합니다. 로그인한 후에 액세스할 계정이나 애플리케이션을 선택할 수 있습니다. 계정에 액세스하려는 경우 관리 세션에 사용할 권한 세트를 선택합니다.
+ OIDC 및 SAML 페더레이션 보안 주체는 사용자 지정 엔터프라이즈 액세스 포털을 사용하여 AWS 계정 로그인에 연결된 외부 ID 공급자를 통해 관리합니다. 사용자가 사용할 수 있는 AWS 리소스는 해당 조직에서 선택한 정책에 따라 달라집니다.
**참고**
추가적으로 보안을 강화하기 위해 루트 사용자, IAM 사용자 및 IAM Identity Center 사용자는 AWS 리소스에 대한 액세스 권한을 부여하기 전에 AWS에서 확인하는 다중 인증(MFA)을 이용할 수 있습니다. MFA가 활성화되는 경우 로그인하려면 MFA 디바이스에 대한 액세스 권한도 있어야 합니다.
다양한 사용자가 관리 콘솔에 로그인하는 방법에 대해 자세히 알아보려면 *AWS 로그인 사용 설명서*의 [AWS Management Console에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html)을 참조하세요.
## AWS 명령줄 도구
AWS 명령줄 도구를 통해 시스템 명령줄에서 명령을 실행하여 IAM 및 AWS 작업을 수행할 수 있습니다. 명령줄을 사용하는 것이 콘솔을 사용하는 것보다 더 빠르고 편리할 수 있습니다. AWS 작업을 수행하는 스크립트를 작성할 때도 명령줄 도구가 유용합니다.
에서는 [AWS Command Line Interface](https://aws.amazon.com/cli/)(AWS CLI) 및 [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/)이라는 두 가지 명령줄 도구 세트를 제공합니다. AWS CLI 설치 및 사용에 대한 자세한 내용은 [AWS Command Line Interface 사용 설명서](https://docs.aws.amazon.com/cli/latest/userguide/)를 참조하세요. Tools for Windows PowerShell 도구 설치 및 사용에 대한 자세한 내용은 [AWS Tools for PowerShell 사용 설명서](https://docs.aws.amazon.com/powershell/latest/userguide/)를 참조하세요.
콘솔에 로그인한 후 브라우저에서 AWS CloudShell을 사용하여 CLI 또는 SDK 명령을 실행할 수 있습니다. AWS 리소스 액세스 권한은 콘솔에 로그인할 때 사용하는 보안 인증에 기반합니다. 경험에 따라 AWS 계정을 관리하는 데 CLI가 더 효율적일 수 있습니다. 자세한 내용은 [AWS CloudShell을 사용하여 AWS Identity and Access Management에서 작업](using-aws-with-cloudshell.md) 섹션을 참조하세요.
### AWS Command Line Interface(CLI) 및 소프트웨어 개발 키트(SDK)
IAM Identity Center 및 IAM 사용자는 CLI 또는 관련 SDK의 애플리케이션 인터페이스(API)를 통해 인증할 때 다양한 방법을 사용하여 보안 인증을 인증합니다.
보안 인증 및 구성 설정은 시스템 또는 사용자 환경 변수, 로컬 AWS 구성 파일 또는 명령줄에서 파라미터로 명시적으로 선언된 위치 등 다양한 장소에 있습니다. 특정 위치가 다른 위치보다 우선합니다.
IAM Identity Center 및 IAM 모두 CLI 또는 SDK에서 사용할 수 있는 액세스 키를 제공합니다. IAM Identity Center 액세스 키는 자동으로 새로 고칠 수 있는 임시 보안 인증이며 IAM 사용자에게 연결된 장기 액세스 키보다 권장됩니다.
CLI 또는 SDK를 사용하여 AWS 계정을 관리하려면 브라우저에서 AWS CloudShell을 사용할 수 있습니다. CloudShell을 사용하여 CLI 또는 SDK 명령을 실행하는 경우 먼저 콘솔에 로그인해야 합니다. AWS 리소스 액세스 권한은 콘솔에 로그인할 때 사용하는 보안 인증에 기반합니다. 경험에 따라 AWS 계정을 관리하는 데 CLI가 더 효율적일 수 있습니다.
애플리케이션 개발의 경우 CLI 또는 SDK를 컴퓨터에 다운로드하고 명령 프롬프트 또는 도커 창에서 로그인할 수 있습니다. 이 시나리오에서는 CLI 스크립트 또는 SDK 애플리케이션의 일부로 인증 및 액세스 보안 인증을 구성합니다. 환경 및 사용 가능한 액세스 권한에 따라 다양한 방식으로 리소스에 대한 프로그래밍 방식의 액세스를 구성할 수 있습니다.
+ AWS 서비스를 통해 로컬 코드를 인증하는 경우 IAM Identity Center 및 IAM Roles Anywhere를 사용하는 것이 좋습니다.
+ AWS 환경 내에서 실행되는 코드를 인증하는 경우 IAM 역할을 사용하거나 IAM Identity Center 보안 인증을 사용하는 것이 좋습니다.
AWS 액세스 포털을 사용하여 로그인하는 경우 권한 세트를 선택하는 시작 페이지에서 단기 자격 증명을 가져올 수 있습니다. 이러한 보안 인증은 기간이 정의되어 있으며 자동으로 새로 고쳐지지 않습니다. 이러한 보안 인증을 사용하려면 AWS 포털에 로그인한 후 AWS 계정을 선택하고 권한 세트를 선택합니다. **명령줄 또는 프로그래밍 방식의 액세스**를 선택하여 프로그래밍 방식으로 또는 CLI에서 AWS 리소스에 액세스하는 데 사용할 수 있는 옵션을 확인합니다. 이러한 방법에 대한 자세한 내용은 *IAM Identity Center 사용 설명서*의 [Getting and refreshing temporary credentials](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html#how-to-get-temp-credentials)를 참조하세요. 이러한 보안 인증은 애플리케이션 개발 중에 코드를 신속하게 테스트하기 위해 자주 사용됩니다.
AWS 리소스에 대한 액세스를 자동화하는 경우 자동으로 새로 고쳐지는 IAM Identity Center 보안 인증을 사용하는 것이 좋습니다. IAM Identity Center에서 사용자 및 권한 세트를 구성한 경우 `aws configure sso` 명령을 사용하여 사용 가능한 보안 인증을 식별하고 프로파일에 저장하는 데 도움이 되는 명령줄 마법사를 사용합니다. 프로파일 구성에 대한 자세한 내용은 *AWS Command Line Interface 버전 2 사용 설명서*의 [`aws configure sso` 마법사를 사용하여 프로파일 구성](https://docs.aws.amazon.com/cli/latest/userguide/sso-configure-profile-token.html#sso-configure-profile-token-auto-sso)을 참조하세요.
**참고**
많은 샘플 애플리케이션에서 IAM 사용자 또는 루트 사용자에 연결된 장기 액세스 키를 사용합니다. 장기 보안 인증은 샌드박스 환경에서 학습 체험의 일환으로만 사용해야 합니다. [장기 액세스 키의 대안](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys)을 검토하고 가능한 한 빨리 IAM Identity Center 보안 인증 또는 IAM 역할과 같은 대체 보안 인증을 사용하도록 코드를 전환할 계획을 수립합니다. 코드를 전환한 후에는 액세스 키를 삭제합니다.
CLI 구성에 대한 자세한 내용은 *AWS Command Line Interface 버전 2 사용 설명서*의 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 *AWS Command Line Interface 사용 설명서*의 [보안 인증 정보 인증 및 액세스](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html)를 참조하세요.
SDK 구성에 대한 자세한 내용은 *AWS SDK 및 도구 참조 가이드*의 [IAM Identity Center authentication](https://docs.aws.amazon.com/sdkref/latest/guide/access-sso.html) 및 *AWS SDK 및 도구 참조 가이드*의 [IAM Roles Anywhere](https://docs.aws.amazon.com/sdkref/latest/guide/access-rolesanywhere.html)를 참조하세요.
## AWS SDK 사용
AWS에서는 다양한 프로그래밍 언어 및 플랫폼(Java, Python, Ruby, .NET, iOS, Android 등)을 위한 라이브러리와 샘플 코드로 구성된 소프트웨어 개발 키트(SDK)를 제공합니다. SDK를 사용하면 편리하게 IAM 및 AWS에 프로그래밍 방식으로 액세스할 수 있습니다. 예를 들어 SDK는 요청에 암호화 방식으로 서명, 오류 관리 및 자동으로 요청 재시도와 같은 작업을 처리합니다. 다운로드 및 설치 방법을 비롯하여 AWS SDK에 대한 자세한 내용은 [Amazon Web Services용 도구](https://aws.amazon.com/tools/) 페이지를 참조하세요.
## IAM 쿼리 API 사용
서비스로 직접 HTTPS 요청을 실행할 수 있는 IAM 쿼리 API를 사용하여 프로그래밍 방식으로 IAM 및 AWS에 액세스할 수 있습니다. 쿼리 API를 사용할 때는 자격 증명을 사용하여 요청에 디지털 방식으로 서명하는 코드를 포함해야 합니다. 자세한 내용은 [HTTP 쿼리 요청을 사용하여 IAM API 호출](programming.md) 및 [IAM API 참조](https://docs.aws.amazon.com/IAM/latest/APIReference/)를 참조하세요.
# IAM 작동 방식
AWS Identity and Access Management는 AWS 계정에 대한 인증 및 권한 부여를 제어하는 데 필요한 인프라를 제공합니다.
먼저, 실제 사용자나 애플리케이션이 AWS를 통해 로그인 보안 인증을 사용하여 인증합니다. IAM은 로그인 보안 인증 정보를 AWS 계정이 신뢰하는 보안 주체(IAM 사용자, AWS STS 페더레이션 사용자 보안 주체, IAM 역할 또는 애플리케이션)에 일치시키고 AWS에 액세스할 수 있는 권한을 인증합니다.
다음으로 IAM은 리소스 액세스 권한을 보안 주체에게 부여하도록 요청합니다. IAM은 권한 부여 요청에 대한 응답으로 액세스 권한을 부여하거나 거부합니다. 예를 들어, 콘솔에 처음 로그인하고 콘솔 홈 페이지에 있는 경우에는 특정 서비스에 액세스하고 있지 않습니다. 서비스를 선택하면 해당 서비스에 대한 권한 부여 요청이 IAM에 전송됩니다. IAM은 권한이 부여된 사용자 목록에 ID가 있는지 확인하고, 부여된 액세스 권한 수준을 제어하는 정책을 결정하고, 적용될 수 있는 다른 정책이 있는지 평가합니다. AWS 계정 내의 보안 주체나 신뢰할 수 있는 다른 AWS 계정의 보안 주체는 권한 부여를 요청할 수 있습니다.
권한이 부여된 후 보안 주체가 AWS 계정에서 리소스에 작업 또는 연산을 수행할 수 있습니다. 예를 들어, 보안 주체는 새 Amazon Elastic Compute Cloud 인스턴스를 시작하거나, IAM 그룹 멤버십을 수정하거나, Amazon Simple Storage Service 버킷을 삭제할 수 있습니다. 다음 다이어그램은 IAM 인프라를 통한 이 프로세스를 보여줍니다.
![\[이 다이어그램은 다른 AWS 서비스나 리소스에서 작업 또는 연산을 수행하도록 IAM 서비스가 보안 주체를 인증하고 권한을 부여하는 방법을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/intro-diagram _policies_800.png)
## 요청 구성 요소
보안 주체가 AWS Management Console, AWS API 또는 AWS CLI를 사용하려고 시도하면 해당 보안 주체가 *요청*을 AWS에 전송합니다. 이 요청에는 다음 정보가 포함되어 있습니다.
+ **작업 또는 연산** - 보안 주체가 수행하려는 작업 또는 연산입니다(예: AWS Management Console에서의 작업이나 AWS CLI 또는 AWS API에서의 연산).
+ **리소스** - 보안 주체가 작업 또는 연산 수행을 요청하는 AWS 리소스 객체입니다.
+ **보안 주체** – 엔터티(사용자 또는 역할)를 사용하여 요청을 보내는 사람 또는 애플리케이션입니다. 보안 주체에 대한 정보에는 권한 정책이 포함됩니다.
+ **환경 데이터** – IP 주소, 사용자 에이전트, SSL 사용 상태, 타임스탬프에 대한 정보입니다.
+ **리소스 데이터** - DynamoDB 테이블 이름 또는 Amazon EC2 인스턴스의 태그 등 요청된 리소스와 관련된 데이터입니다.
AWS가 요청 정보를 *요청 콘텍스트*에 수집하면 IAM이 평가하여 요청 권한을 부여합니다.
## 보안 주체가 인증되는 방법
보안 주체는 보안 인증 정보를 사용하여 AWS에 로그인하고 IAM은 이 보안 인증 정보를 인증하여 보안 주체가 AWS에 요청을 보내도록 허용합니다. Amazon S3 및 AWS STS 등의 일부 서비스는 익명 사용자의 특정 요청을 허용합니다. 하지만 이는 규칙의 예외입니다. 각 유형의 사용자는 인증을 거칩니다.
+ **루트 사용자** - 인증에 사용되는 로그인 보안 인증 정보는 AWS 계정을 만들 때 사용한 이메일 주소와 당시 지정한 암호입니다.
+ ****페더레이션 보안 주체 - ID 공급자가 사용자를 인증하고 자격 증명을 AWS에 전달하므로 AWS에 직접 로그인하지 않아도 됩니다. IAM Identity Center와 IAM 모두 ID 페더레이션을 지원합니다.
+ **AWS IAM Identity Center 디렉터리의 사용자***(페더레이션 아님)* - IAM Identity Center 기본 디렉터리에서 직접 생성된 사용자는 AWS 액세스 포털을 사용하여 로그인하고 사용자 이름과 암호를 입력합니다.
+ **IAM 사용자** - 계정 ID 또는 별칭, 사용자 이름, 암호를 입력하여 로그인합니다. API 또는 AWS CLI에서 워크로드를 인증하려면 역할 수임을 통해 임시 보안 인증 정보를 사용하거나 액세스 키와 비밀 키를 제공하여 장기 보안 인증 정보를 사용합니다.
IAM 엔터티에 대한 자세한 내용은 [IAM 사용자](id_users.md) 및 [IAM 역할](id_roles.md) 섹션을 참조하세요.
AWS는 모든 사용자에 다중 인증(MFA)을 사용하여 계정의 보안을 강화하는 것을 권장합니다. MFA에 대한 자세한 내용은 [IAM의 AWS 다중 인증](id_credentials_mfa.md) 섹션을 참조하세요.
## 권한 부여 및 권한 정책 기본 사항
권한 부여란 보안 주체가 요청을 완료하는 데 필요한 권한을 갖는 것을 말합니다. IAM은 권한 부여 과정에서 요청 컨텍스트의 값을 사용하여 요청에 적용되는 정책을 식별합니다. 그런 다음 이것은 정책을 사용하여 요청을 허용하거나 거부할지 여부를 결정합니다. IAM은 대부분의 권한 정책을 보안 주체 엔터티의 권한을 지정하는 [JSON 문서](access_policies.md#access_policies-json)로 저장합니다.
권한 부여 요청에 영향을 미칠 수 있는 [몇 가지 정책 유형](access_policies.md)이 있습니다. 계정의 AWS 리소스에 액세스할 수 있는 권한을 사용자에게 제공하려면 자격 증명 기반 정책을 사용할 수 있습니다. 리소스 기반 정책은 [크로스 계정 액세스](access_permissions-required.md#UserPermissionsAcrossAccounts) 권한을 부여할 수 있습니다. 다른 계정에서 요청하려면 다른 계정의 정책에서 해당 리소스에 대한 액세스를 허용해야 하며, *또한* 요청하는 데 사용하는 IAM 엔터티에 해당 요청을 허용하는 자격 증명 기반 정책이 있어야 합니다.
IAM은 요청 컨텍스트에 적용되는 각 정책을 확인합니다. IAM 정책 평가는 *명시적 거부*를 사용합니다. 즉, 단일 권한 정책에 거부된 작업이 포함된 경우 IAM은 전체 요청을 거부하고 평가를 중지합니다. 요청이 **기본적으로 거부되므로 IAM이 요청 권한을 부여하려면 관련 권한 정책에서 요청의 모든 부분을 허용해야 합니다. 단일 계정 내 요청 평가 로직은 다음과 같은 기본 규칙을 따릅니다.
+ 기본적으로 모든 요청을 거부합니다. (일반적으로, AWS 계정 루트 사용자 증명을 사용하여 해당 계정의 리소스를 요청하는 경우는 항상 허용됩니다.)
+ 권한 정책(자격 증명 기반 또는 리소스 기반)에 포함된 명시적 허용은 이 기본 작동을 재정의합니다.
+ AWS Organizations 서비스 제어 정책(SCP)이나 리소스 제어 정책(RCP), IAM 권한 경계 또는 세션 정책이 있는 경우 허용이 재정의됩니다. 하나 이상의 이러한 정책 유형이 존재하는 경우 이들 정책 유형 모두가 해당 요청을 허용해야 합니다. 그렇지 않은 경우 묵시적으로 거부됩니다. SCP 및 RCP에 대한 자세한 내용은 *AWS Organizations 사용 설명서*의 [Authorization policies in AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html)를 참조하세요.
+ 정책의 명시적 거부는 정책의 모든 허용을 무시합니다.
자세한 내용은 [정책 평가 로직](reference_policies_evaluation-logic.md)를 참조하세요.
IAM이 보안 주체를 인증하고 권한을 부여한 후, IAM은 보안 주체에 적용되는 권한 정책을 평가하여 요청의 작업이나 연산을 승인합니다. 각 AWS 서비스는 지원하는 작업(연산)을 정의하며, 리소스 보기, 생성, 편집, 삭제 등 리소스에 대해 수행할 수 있는 작업을 포함합니다. 보안 주체에 적용되는 권한 정책에는 연산을 수행하는 데 필요한 작업이 포함되어야 합니다. IAM이 권한 정책을 평가하는 방법에 대한 자세한 내용은 [정책 평가 로직](reference_policies_evaluation-logic.md) 섹션을 참조하세요.
서비스는 각 리소스에서 보안 주체가 수행할 수 있는 일련의 작업을 정의합니다. 권한 정책을 생성할 때는 사용자가 수행할 수 있게 하려는 작업을 포함해야 합니다. 예를 들어 IAM은 다음 기본 작업을 비롯하여 사용자 리소스에 대한 40개 이상의 작업을 지원합니다.
+ `CreateUser`
+ `DeleteUser`
+ `GetUser`
+ `UpdateUser`
또한 요청이 조건을 충족할 때 리소스 액세스 권한을 제공하는 조건을 권한 정책에 지정할 수 있습니다. 예를 들어 특정 날짜 이후에만 정책문이 적용되도록 하거나 API에 특정 값이 표시되는 경우에 액세스를 제어하려 할 수 있습니다. 조건을 지정하려면 정책문의 [`Condition`](reference_policies_elements_condition_operators.md) 요소를 사용합니다.
IAM이 요청의 연산을 승인하면 보안 주체가 계정 내 관련 리소스에서 해당 작업을 수행할 수 있습니다. 리소스는 서비스 내에 존재하는 객체입니다. 예를 들어 Amazon EC2 인스턴스, IAM 사용자 및 Amazon S3 버킷이 있습니다. 보안 주체가 권한 정책에 포함되지 않은 리소스에 대한 작업을 수행하기 위한 요청을 생성하면 서비스는 요청을 거부합니다. 예를 들어 IAM 역할을 삭제할 권한이 있지만 IAM 그룹 삭제를 요청하는 경우 IAM 그룹을 삭제할 권한이 없으면 요청이 실패합니다. 다양한 AWS 서비스가 지원하는 작업, 리소스, 조건 키에 대한 자세한 내용은 [Actions, Resources, and Condition Keys for AWS Services](reference_policies_actions-resources-contextkeys.html)를 참조하세요.
# IAM ID 및 자격 증명 비교
AWS Identity and Access Management에서 관리되는 ID는 IAM 사용자, IAM 역할 및 IAM 그룹입니다. 이러한 ID는 AWS가 AWS 계정과 함께 생성한 루트 사용자 외에 사용됩니다.
일상적인 작업, 심지어 관리 작업의 경우에도 루트 사용자를 사용하지 않을 것을 강력히 권장합니다. 대신 추가 사용자를 제공해서 필요한 작업을 수행하는 데 필요한 권한을 해당 사용자에게 부여합니다. IAM Identity Center 디렉터리에 사람을 추가하거나, 외부 ID 공급자를 IAM Identity Center 또는 IAM과 페더레이션하거나, 최소 권한 IAM 사용자를 생성하여 사용자를 추가할 수 있습니다.
보안 강화를 위해 루트 액세스를 중앙 집중화하여 AWS Organizations로 관리되는 AWS 계정의 루트 사용자 자격 증명을 중앙에서 보호하는 것이 좋습니다. [중앙에서 멤버 계정에 대한 루트 액세스 관리](id_root-user.md#id_root-user-access-management)를 통해 장기적인 루트 사용자 자격 증명 복구를 중앙에서 제거하고 방지하여 대규모로 의도치 않은 루트 액세스를 방지할 수 있습니다. 중앙 집중식 루트 액세스를 활성화한 후 권한 있는 세션을 수임하여 멤버 계정에 대한 작업을 수행할 수 있습니다.
사용자를 설정한 후에는 특정 사용자에게 AWS 계정 액세스 권한을 부여하고 리소스에 액세스할 수 있는 권한을 제공할 수 있습니다.
[모범 사례](best-practices.md)로, AWS는 사람이 IAM 역할을 맡아 AWS에 액세스하도록 하여 임시 자격 증명을 사용하도록 하는 것을 권장합니다. IAM Identity Center 디렉터리에서 ID를 관리하거나 ID 공급자와의 페더레이션을 사용하는 경우 모범 사례를 따르고 있는 것입니다.
## 용어
IAM 자격 증명 작업 시 다음과 같은 용어가 일반적으로 사용됩니다.
**IAM 리소스**
IAM 서비스는 다음 리소스를 저장합니다. 이 리소스는 콘솔에서 추가, 편집, 제거할 수 있습니다.
+ IAM 사용자
+ IAM 그룹
+ IAM 역할
+ 권한 정책
+ 자격 증명 공급자 객체
**IAM 엔터티**
AWS이(가) 인증에 사용하는 IAM 리소스. 리소스 기반 정책에서 엔터티를 보안 주체로 지정합니다.
+ IAM 사용자
+ IAM 역할
**IAM 자격 증명**
정책에서 권한을 부여받아 작업을 수행하고 리소스에 액세스할 수 있는 IAM 리소스입니다. ID에는 IAM 사용자, IAM 그룹 및 IAM 역할이 포함됩니다.
![\[이 다이어그램은 IAM 사용자와 IAM 역할이 엔터티이면서 자격 증명이기도 한 보안 주체이지만 루트 사용자는 엔터티도 아니고 자격 증명도 아닌 보안 주체임을 보여줍니다. 다이어그램은 또 IAM 그룹이 자격 증명임을 알려줍니다. IAM 인증은 정책을 사용하여 자격 증명의 액세스를 제어하지만 루트 사용자는 전체 AWS 리소스 액세스 권한을 가지며 자격 증명 또는 리소스 기반 IAM 정책에 의해 제한될 수 없습니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/iam-terms-2.png)
**보안 주체**
AWS 리소스에 대한 작업 또는 연산을 요청할 수 있는 AWS 계정 루트 사용자, IAM 사용자 또는 IAM 역할입니다. 보안 주체에는 인간 사용자, 워크로드, 페더레이션 보안 주체 및 수임된 역할이 포함됩니다. 인증 후 IAM은 보안 주체 유형에 따라 AWS에 요청할 수 있는 영구 또는 임시 보안 인증 정보를 보안 주체에게 부여합니다.
*인간 사용자*는 *인간 자격 증명*이라고도 하며, 애플리케이션의 사용자, 관리자, 개발자, 운영자, 소비자 등입니다.
*워크로드*는 애플리케이션, 프로세스, 운영 도구 및 기타 구성 요소 같이 비즈니스 가치를 창출하는 리소스 및 코드 모음입니다.
**페더레이션 보안 주체는 Active Directory, Okta 또는 Microsoft Entra 같은 다른 ID 공급자가 자격 증명과 보안 인증 정보를 관리하는 사용자입니다.
*IAM 역할*은 계정에서 생성할 수 있고 해당 자격 증명이 수행할 수 있는 작업과 수행할 수 없는 작업을 결정하는 특정 권한을 지닌 IAM 자격 증명입니다. 그러나 역할은 한 사람하고만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있어야 합니다.
IAM은 IAM 사용자와 루트 사용자에게 장기 보안 인증 정보를 부여하고 IAM 역할에 임시 보안 인증 정보를 부여합니다. AWS IAM Identity Center의 사용자, OIDC 및 SAML 페더레이션 보안 주체는 AWS에 로그인할 때 IAM 역할을 수임하고, 임시 자격 증명이 부여됩니다. [가장 좋은 방법](best-practices.md)은 인간 사용자와 워크로드가 임시 보안 인증을 사용하여 AWS 리소스에 액세스하도록 하는 것입니다.
## IAM 사용자와 IAM Identity Center의 사용자의 차이점
**IAM 사용자**는 별도의 계정이 아니라 계정 내의 사용자입니다. 각 사용자에게는 AWS Management Console에 액세스하기 위한 자체 암호가 있습니다. 또한 사용자가 계정의 리소스를 사용하기 위한 프로그래밍 방식의 요청을 할 수 있도록 각 사용자에 대한 개별 액세스 키를 생성할 수 있습니다.
IAM 사용자와 해당 액세스 키에는 AWS 리소스에 대한 장기 보안 인증 정보가 있습니다. IAM 사용자의 주요 용도는 IAM 역할을 사용할 수 없는 워크로드에 API 또는 CLI를 사용하여 AWS 서비스에 프로그래밍 방식으로 요청하는 기능을 제공하는 것입니다.
**참고**
프로그래밍 방식 액세스 권한과 장기 보안 인증이 있는 IAM 사용자가 필요한 시나리오의 경우 필요할 때 액세스 키를 업데이트하는 것이 좋습니다. 자세한 내용은 [액세스 키 업데이트](id-credentials-access-keys-update.md) 섹션을 참조하세요.
작업 인력 자격 증명(사람)은 수행하는 역할에 따라 권한 요구 사항이 다르고 조직 전체의 다양한 AWS 계정에서 작업할 수 있는 **AWS IAM Identity Center의 사용자**입니다. 액세스 키가 필요한 사용 사례가 있는 경우 AWS IAM Identity Center의 사용자를 사용하여 해당 사용 사례를 지원할 수 있습니다. AWS 액세스 포털을 통해 로그인하는 사용자는 AWS 리소스에 대한 단기 자격 증명이 포함된 액세스 키를 얻을 수 있습니다. 중앙 액세스 관리를 위해 [AWS IAM Identity Center(IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)를 사용하여 계정에 대한 액세스 권한과 해당 계정 내 권한을 관리하는 것이 좋습니다. IAM Identity Center는 사용자 및 그룹을 추가하고 AWS 리소스에 대한 액세스 수준을 할당할 수 있는 기본 ID 소스로 Identity Center 디렉터리를 사용하여 자동으로 구성됩니다. 자세한 내용은 AWS IAM Identity Center 사용 설명서에서 [AWS IAM Identity Center란 무엇입니까?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 단원을 참조하세요.**
이 두 유형의 사용자 간의 주요 차이점은 IAM Identity Center의 사용자는 관리 콘솔 또는 AWS 리소스에 액세스하기 전에 AWS에 로그인할 때 자동으로 IAM 역할을 수임한다는 것입니다. IAM 역할은 사용자가 AWS에 로그인할 때마다 임시 보안 인증 정보를 부여합니다. IAM 사용자가 IAM 역할을 사용하여 로그인하려면 역할을 수임하고 전환할 수 있는 권한이 있어야 하며, AWS 계정에 액세스한 후 수임하려는 역할로의 전환을 명시적으로 선택해야 합니다.
## 기존 자격 증명 소스의 사용자 페더레이션
조직 내 사용자가 회사 네트워크에 로그인할 때 이미 인증된 경우 해당 사용자를 위해 별도의 IAM 사용자 또는 IAM Identity Center 사용자를 생성할 필요가 없습니다. 대신 IAM이나 AWS IAM Identity Center 사용을 통해 이러한 사용자 자격 증명을 AWS에 *페더레이션*할 수 있습니다. OIDC 및 SAML 페더레이션 보안 주체는 특정 리소스에 액세스할 수 있는 권한을 부여하는 IAM 역할을 수임합니다. 역할에 관한 자세한 내용은 [역할 용어 및 개념](id_roles.md#id_roles_terms-and-concepts) 섹션을 참조하세요.
![\[다음 다이어그램은 페더레이션 보안 주체가 AWS 계정의 리소스에 액세스하기 위한 임시 AWS 자격 증명을 얻는 방법을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/iam-intro-federation.diagram.png)
페더레이션은 다음과 같은 경우에 유용합니다.
+ **사용자가 이미 기업 디렉터리에 있는 경우.**
기업 디렉터리가 SAML 2.0(Security Assertion Markup Language 2.0)과 호환되는 경우, 기업 디렉터리를 구성하여 사용자에게 AWS Management Console에 대한 Single-Sign On(SSO) 액세스를 제공할 수 있습니다. 자세한 내용은 [임시 자격 증명과 관련된 일반적인 시나리오](id_credentials_temp.md#sts-introduction) 섹션을 참조하세요.
기업 디렉터리가 SAML 2.0과 호환되지 않는 경우, ID 브로커 애플리케이션을 생성하여 사용자에게 AWS Management Console에 대한 Single-Sign On(SSO) 액세스를 제공할 수 있습니다. 자세한 내용은 [AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화](id_roles_providers_enable-console-custom-url.md) 섹션을 참조하세요.
기업 디렉토리가 Microsoft Active Directory인 경우, AWS IAM Identity Center를 사용하여 Active Directory의 자체 관리형 디렉토리 또는 [AWS Directory Service](https://aws.amazon.com/directoryservice/)의 디렉토리에 연결해 기업 디렉토리와 AWS 계정 간의 신뢰를 설정할 수 있습니다.
Okta 또는 Microsoft Entra와 같은 외부 ID 제공업체(IdP)를 사용하여 사용자를 관리하는 경우 AWS IAM Identity Center을 사용하여 IdP와 AWS 계정 간에 신뢰를 설정할 수 있습니다. 자세한 내용은 *AWS IAM Identity Center 사용 설명서*의 [외부 ID 제공업체에 연결](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)을 참조하세요.
+ **사용자가 이미 인터넷 자격 증명을 보유한 경우**
사용자가 Login with Amazon, Facebook, Google 또는 OpenID Connect(OIDC) 호환 자격 증명 공급자 등의 인터넷 자격 증명 공급자를 통해 자신을 식별할 수 있도록 모바일 앱 또는 웹 기반 앱을 만들면, 해당 앱에서 연동을 통해 AWS에 액세스할 수 있습니다. 자세한 내용은 [OIDC 페더레이션](id_roles_providers_oidc.md) 섹션을 참조하세요.
**작은 정보**
인터넷 자격 증명 공급자를 통해 ID 페더레이션을 사용하려면 [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html)를 사용하는 것이 좋습니다.
## 사용자 액세스를 제공하는 다양한 방법
다음은 AWS 리소스에 대한 액세스 권한을 제공할 수 있는 방법입니다.
****
| 사용자 액세스 유형 | 언제 사용되나요? | 자세한 정보는 어디에 있나요? |
| --- | --- | --- |
| 작업 인력 사용자 등 사람이 IAM Identity Center를 사용하여 AWS 리소스에 액세스하기 위한 Single Sign-On 액세스 | IAM Identity Center는 사용자의 관리와 AWS 계정 및 클라우드 애플리케이션에 대한 액세스를 통합하는 중앙 위치를 제공합니다. IAM Identity Center 내에서 ID 스토어를 설정하거나 기존 ID 제공업체(idP)와의 페더레이션을 구성할 수 있습니다. 보안상 가장 좋은 방법은 인간 사용자에게 AWS 리소스에 대한 제한된 보안 인증 정보를 부여하는 것입니다. 사용자는 보다 쉽게 로그인할 수 있으며 단일 시스템에서 리소스에 대한 액세스를 제어할 수 있습니다. IAM Identity Center는 추가 계정 보안을 위해 다중 인증(MFA)을 지원합니다. | IAM Identity Center 설정에 대한 자세한 내용은 *AWS IAM Identity Center 사용 설명서*의 [Getting Started](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)(시작하기)를 참조하세요. IAM Identity Center의 MFA 사용에 대한 자세한 내용은 *AWS IAM Identity Center 사용 설명서*의 [Multi-factor authentication](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)(다중 인증)을 참조하세요. |
| 작업 인력 사용자 등 인간 사용자가 IAM ID 제공업체(IdP)를 사용하여 AWS 서비스에 액세스하기 위한 페더레이션 액세스 | IAM은 OpenID Connect(OIDC) 또는 SAML 2.0(Security Assertion Markup Language 2.0)과 호환되는 IdP를 지원합니다. IAM ID 공급자를 생성한 후 페더레이션 보안 주체에게 동적으로 할당할 수 있는 IAM 역할을 하나 이상 생성합니다. | IAM ID 제공업체 및 페더레이션에 대한 자세한 내용은 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 섹션을 참조하세요. |
| AWS 계정 간 크로스 계정 액세스 | 일부 AWS 리소스에 대한 액세스를 AWS 계정의 사용자와 공유하려고 합니다. 역할은 교차 계정 액세스를 부여하는 기본적인 방법입니다. 그러나 일부 AWS 서비스는 (역할을 프록시로 사용하는 대신) 정책을 리소스에 직접 연결할 수 있는 리소스 기반 정책을 지원합니다. | IAM 역할에 대한 자세한 내용은 [IAM 역할](id_roles.md) 섹션을 참조하세요. 서비스 연결 역할에 대한 자세한 내용은 [서비스 연결 역할 생성](id_roles_create-service-linked-role.md)를 참조하세요. 서비스 연결 역할 사용을 지원하는 서비스에 대한 자세한 내용은 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md) 섹션을 참조하세요. **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾습니다. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 해당 열의 **예**와 연결된 링크를 선택하세요. |
| AWS 계정의 지정된 IAM 사용자를 위한 장기 보안 인증 | AWS에서 IAM 사용자의 장기 보안 인증이 필요한 특정 사용 사례가 있을 수 있습니다. IAM을 사용하여 AWS 계정에서 이러한 IAM 사용자를 생성하고 IAM을 사용하여 해당 권한을 관리할 수 있습니다. 일부 사용 사례는 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/introduction_identity-management.html) [프로그래밍 방식 액세스 및 장기 보안 인증](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)이 있는 IAM 사용자가 필요한 시나리오에서는 [모범 사례](best-practices.md)로, 필요할 때 액세스 키를 업데이트하는 것이 좋습니다. 자세한 내용은 [액세스 키 업데이트](id-credentials-access-keys-update.md) 섹션을 참조하세요. | IAM 사용자 설정에 대한 자세한 내용은 [AWS 계정에서 IAM 사용자 생성](id_users_create.md) 섹션을 참조하세요. IAM 사용자 액세스 키에 대한 자세한 내용은 [IAM 사용자의 액세스 키 관리](id_credentials_access-keys.md) 섹션을 참조하세요. AWS CodeCommit 또는 Amazon Keyspaces에 대한 서비스별 보안 인증에 대한 자세한 내용은 [CodeCommit용 IAM 자격 증명: Git 자격 증명, SSH 키 및 AWS 액세스 키](id_credentials_ssh-keys.md) 및 [Amazon Keyspaces(Apache Cassandra용)와 함께 IAM 사용](id_credentials_keyspaces.md) 섹션을 참조하세요. |
## 프로그래밍 방식의 사용자 액세스 지원
사용자가 AWS Management Console 외부에서 AWS와 상호 작용하려면 프로그래밍 방식의 액세스 권한이 필요합니다. 프로그래밍 방식으로 액세스를 부여하는 방법은 AWS에 액세스하는 사용자 유형에 따라 다릅니다.
+ IAM Identity Center에서 ID를 관리하는 경우 AWS API에는 프로필이 필요하고 AWS Command Line Interface에는 프로필이나 환경 변수가 필요합니다.
+ IAM 사용자가 있는 경우 AWS API 및 AWS Command Line Interface에는 액세스 키가 필요합니다. 가능한 경우 액세스 키 ID, 비밀 액세스 키 및 보안 인증 정보가 만료되는 시간을 나타내는 보안 토큰으로 구성된 임시 보안 인증 정보를 만듭니다.
사용자에게 프로그래밍 방식 액세스 권한을 부여하려면 다음 옵션 중 하나를 선택합니다.
| 프로그래밍 방식 액세스가 필요한 사용자 | 옵션 | 추가 정보 |
| --- | --- | --- |
| 작업 인력 ID (IAM Identity Center에서 관리되는 사람 및 사용자) | 단기 자격 증명을 사용하여 AWS CLI 또는 AWS API에 대한 프로그래밍 방식 요청에 직접 또는 AWS SDK를 사용하여 서명하려 합니다. | AWS CLI의 경우 *AWS IAM Identity Center 사용 설명서*의 [CLI 액세스를 위한 IAM 역할 보안 인증 정보 가져오기](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtogetcredentials.html)에 나와 있는 지침을 따르세요. AWS API의 경우 *AWS SDK 및 도구 참조 가이드*의 [SSO 보안 인증 정보](https://docs.aws.amazon.com//sdkref/latest/guide/feature-sso-credentials.html)에 나와 있는 지침을 따르세요. |
| IAM 사용자 | 단기 자격 증명을 사용하여 AWS CLI 또는 AWS API에 대한 프로그래밍 방식 요청에 직접 또는 AWS SDK를 사용하여 서명하려 합니다. | [AWS 리소스로 임시 보안 인증 정보 사용](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_use-resources.html)에 나와 있는 지침을 따르세요. |
| IAM 사용자 | 장기 보안 인증 정보를 사용하여 AWS CLI 또는 AWS API에 대한 프로그래밍 방식 요청에 직접 또는 AWS SDK를 사용하여 서명할 수 있습니다.(권장되지 않음) | [IAM 사용자 액세스 키 관리](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html)에 나와 있는 지침을 따르세요. |
| 페더레이션 보안 주체 | AWS STS API 작업을 사용하여 액세스 키 페어 및 세션 토큰을 포함하는 임시 보안 인증 정보로 새 세션을 생성합니다. | API 작업에 대한 설명은 [임시 보안 자격 증명 요청](id_credentials_temp_request.md) 섹션을 참조하세요. |
# 권한 및 정책이 액세스 관리를 제공하는 방법
AWS Identity and Access Management(IAM)의 액세스 관리를 통해 계정에서 보안 주체 엔터티에 허용된 권한을 정의할 수 있습니다. 보안 주체 엔터티란 IAM 엔터티(IAM 사용자 또는 IAM 역할)를 사용하여 인증된 사람 또는 애플리케이션입니다. 액세스 관리를 흔히 *권한 부여*라고 합니다. 정책을 생성하고 IAM ID(IAM 사용자, IAM 그룹 또는 IAM 역할) 또는 AWS 리소스에 연결하여 AWS에서 액세스를 관리합니다. 정책은 ID 또는 리소스와 연결될 때 해당 권한을 정의하는 AWS의 객체입니다. AWS는 보안 주체가 IAM 엔터티(IAM 사용자 또는 IAM 역할)를 사용하여 요청할 때 이러한 정책을 평가합니다. 정책에서 권한은 요청이 허용되거나 거부되는 지를 결정합니다. 대부분의 정책은 AWS에 JSON 문서로 저장됩니다. 정책 유형 및 활용에 대한 자세한 정보는 [AWS Identity and Access Management의 정책 및 권한](access_policies.md) 섹션을 참조하세요.
## 정책 및 계정
AWS에서 하나의 계정을 관리하려면 정책을 사용하여 해당 계정 내 권한을 정의합니다. 여러 계정 전반의 권한을 관리하고자 한다면 IAM 사용자에 대한 권한을 관리하기가 더 어렵습니다. 크로스 계정 권한에 대해 IAM 역할, 리소스 기반 정책 또는 액세스 제어 목록(ACL)을 사용할 수 있습니다. 하지만 여러 계정을 소유하는 경우에는 이러한 권한을 쉽게 관리할 수 있도록 ACL 대신에 AWS Organizations 서비스를 사용하는 것이 좋습니다. 자세한 내용은 *AWS Organizations 사용 설명서*의 [AWS Organizations이란?](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)을 참조하세요.
## 정책 및 사용자
IAM 사용자는 AWS 계정의 ID입니다. IAM 사용자를 생성할 경우, 권한을 부여하지 않는 한 사용자는 계정 내에서 어떠한 것으로도 액세스할 수 없습니다. IAM 사용자 또는 IAM 사용자가 속한 IAM 그룹에 연결된 정책인 자격 증명 기반 정책을 생성하여 IAM 사용자에게 권한을 부여합니다. 다음 예제는 IAM 사용자가 `us-east-2` 리전 내의 `123456789012` 계정에서 `Books` 테이블의 모든 Amazon DynamoDB 작업(`dynamodb:*`)을 수행할 수 있도록 허용하는 JSON 정책을 보여줍니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books"
}
}
```
------
이 정책을 IAM 사용자에게 연결하면 해당 사용자는 DynamoDB 인스턴스의 `Books` 테이블에서 모든 작업을 수행할 권한을 갖습니다. 대부분의 IAM 사용자에게는 부여된 전체 권한을 나타내는 여러 정책의 조합이 있습니다.
정책에 의해 명시적으로 허용되지 않은 작업 또는 리소스는 기본적으로 모두 거부됩니다. 예를 들어 앞의 정책이 사용자에게 연결된 단일 정책이라면 이 사용자는 `Books` 테이블에서 DynamoDB 작업을 수행할 수 있지만 다른 테이블에서는 작업을 수행할 수 없습니다. 마찬가지로 이 사용자는 Amazon EC2, Amazon S3 또는 기타 다른 AWS 서비스에서 어떠한 작업도 수행할 수 없습니다. 이러한 서비스에서 작업할 수 있는 권한이 정책에 포함되지 않기 때문입니다.
## 정책 및 IAM 그룹
IAM 사용자를 *IAM 그룹*으로 구성하고 IAM 그룹에 정책을 연결할 수 있습니다. 이 경우 각 IAM 사용자는 별도의 자격 증명을 갖고 있지만 IAM 그룹의 모든 IAM 사용자에게는 IAM 그룹에 연결된 권한이 있습니다. IAM 그룹을 사용하여 간편하게 권한을 관리합니다.
![\[이 다이어그램은 IAM 사용자를 IAM 그룹으로 구성하여 권한을 간편하게 관리할 수 있는 방법을 보여줍니다(각 IAM 사용자에게 IAM 그룹에 할당된 권한이 있으므로).\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/iam-intro-users-and-groups.diagram.png)
IAM 사용자 또는 IAM 그룹에 여러 정책을 연결하여 다양한 권한을 부여할 수 있습니다. 이 경우 정책의 조합이 보안 주체의 유효 권한을 결정합니다. 특정 작업과 리소스 모두에 대한 명시적 `Allow` 권한이 없는 보안 주체에게는 이러한 권한이 없는 것입니다.
## 페더레이션 사용자 세션 및 역할
페더레이션 보안 주체에게는 IAM 사용자처럼 AWS 계정에서 영구적인 ID가 부여되지 않습니다. 페더레이션 보안 주체에게 권한을 부여하려면 **역할이라고 하는 엔터티를 만들고 해당 역할의 권한을 정의할 수 있습니다. SAML 또는 OIDC 페더레이션 보안 주체가 AWS에 로그인하면 사용자가 역할과 연결되고 역할에 정의된 권한이 부여됩니다. 자세한 내용은 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md) 섹션을 참조하세요.
## 자격 증명 기반 정책 및 리소스 기반 정책
자격 증명 기반 정책은 IAM 사용자, 그룹 또는 역할과 같은 IAM 자격 증명에 연결할 수 있는 권한 정책입니다. 리소스 기반 정책은 Amazon S3 버킷 또는 IAM 역할 신뢰 정책과 같은 리소스에 연결하는 권한 정책입니다.
***자격 증명 기반 정책***은 자격 증명이 수행할 수 있는 작업, 대상 리소스 및 이에 관한 조건을 제어합니다. 자격 증명 기반 정책을 추가로 분류할 수 있습니다.
+ **관리형 정책** - AWS 계정에 속한 다수의 사용자, 그룹 및 역할에 독립적으로 연결할 수 있는 자격 증명 기반 정책입니다. 사용할 수 있는 관리형 정책은 두 가지가 있습니다.
+ **AWS 관리형 정책** - AWS에서 생성 및 관리하는 관리형 정책입니다. 정책 사용이 처음이라면 AWS 관리형 정책 사용을 먼저 권장합니다.
+ **고객 관리형 정책** - 사용자가 자신의 AWS 계정에서 생성 및 관리하는 관리형 정책입니다. 고객 관리형 정책은 AWS 관리형 정책보다 정책에 대해 더욱 정밀하게 제어할 수 있습니다. 시각적 편집기에서 또는 JSON 정책 문서를 직접 생성하여 IAM 정책을 생성, 편집 및 검증할 수 있습니다. 자세한 내용은 [고객 관리형 정책으로 사용자 지정 IAM 권한 정의](access_policies_create.md) 및 [IAM 정책 편집](access_policies_manage-edit.md)을(를) 참조하세요.
+ **인라인 정책** - 자신이 생성 및 관리하며, 단일 사용자, 그룹 또는 역할에 직접 포함되는 정책입니다. 대부분의 경우 인라인 정책을 사용하지 않는 것이 좋습니다.
***리소스 기반 정책***은 지정된 보안 주체가 해당 리소스에 대해 수행할 수 있는 작업 및 이에 관한 조건을 제어합니다. 리소스 기반 정책은 인라인 정책이며, 관리형 리소스 기반 정책은 없습니다. 크로스 계정 액세스를 활성화하는 경우, 전체 계정이나 다른 계정의 IAM 엔터티를 리소스 기반 정책의 보안 주체로 지정할 수 있습니다.****
IAM 서비스는 역할 *신뢰 정책*이라고 하는 리소스 기반 정책 유형 하나를 지원하며, 이 정책을 IAM 역할에 연결합니다. IAM 역할은 리소스 기반 정책을 지원하는 자격 증명이자 리소스이므로 신뢰 정책과 자격 증명 기반 정책 모두 IAM 역할에 연결해야 합니다. 신뢰 정책은 역할을 수임할 수 있는 보안 주체 엔터티(계정, 사용자, 역할 및 AWS STS 페더레이션 사용자 보안 주체)를 정의합니다. IAM 역할과 다른 리소스 기반 정책 간의 차이에 대해 알아보려면 [IAM의 크로스 계정 리소스 액세스](access_policies-cross-account-resource-access.md) 섹션을 참조하세요.
리소스 기반 정책을 지원하는 서비스를 보려면 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md) 단원을 참조하십시오. 리소스 기반 정책에 대해 자세히 알아보려면 [자격 증명 기반 정책 및 리소스 기반 정책](access_policies_identity-vs-resource.md) 섹션을 참조하세요.
# ABAC 권한 부여를 통한 속성 기반 권한 정의
ABAC(속성 기반 액세스 제어)는 속성을 기준으로 권한을 정의하는 권한 부여 전략입니다. AWS에서는 이 속성을 *태그*라고 합니다. IAM 엔터티(IAM 사용자 또는 IAM 역할)를 포함하는 IAM 리소스와 AWS 리소스에 태그를 연결할 수 있습니다. IAM 보안 주체에 대해 단일 ABAC 정책 또는 작은 정책 세트를 생성할 수 있습니다. 보안 주체의 태그가 리소스 태그와 일치할 때 작업을 허용하도록 ABAC 정책을 설계할 수 있습니다. ABAC의 속성 시스템은 높은 사용자 컨텍스트와 세분화된 액세스 제어를 모두 제공합니다. ABAC는 속성 기반이므로 실시간으로 액세스 권한을 부여하거나 취소하는 데이터 또는 애플리케이션에 대해 동적 권한 부여를 수행할 수 있습니다. ABAC는 확장 중인 환경과 자격 증명 또는 리소스 정책 관리가 복잡해진 상황에서 유용합니다.
예를 들어, `access-project` 태그 키를 사용하여 세 개의 IAM 역할을 생성할 수 있습니다. 첫 번째 IAM 역할의 태그 값을 `Heart`로, 두 번째 역할의 태그 값을 `Star`로, 세 번째 역할의 태그 값을 `Lightning`으로 설정합니다. 그런 다음 IAM 역할과 AWS 리소스에 태그 값 `access-project`가 있을 때 액세스를 허용하는 단일 정책을 사용할 수 있습니다. AWS에서 ABAC를 사용하는 방법을 보여 주는 자세한 자습서는 [IAM 튜토리얼: 태그를 기반으로 AWS 리소스에 액세스할 수 있는 권한 정의](tutorial_attribute-based-access-control.md) 섹션을 참조하세요. ABAC를 지원하는 서비스에 대해 알아보려면 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)을 참조하세요.
![\[이 다이어그램은 사용자에게 리소스에 대한 권한을 부여하려면 보안 주체에 적용된 태그가 리소스에 적용된 태그와 일치해야 한다는 것을 보여줍니다. 태그는 IAM 그룹, 리소스 그룹, 개별 사용자 및 개별 리소스에 적용됩니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/tutorial-abac-concept-23.png)
## ABAC와 기존 RBAC 모델 비교
IAM에 사용되는 기존 권한 부여 모델은 RBAC(역할 기반 액세스 제어)입니다. RBAC는 IAM 역할과 구별되는 개인의 직무나 *역할*에 따라 권한을 정의합니다. IAM에는 [직무에 관한 관리형 정책](access_policies_job-functions.md)이 있어 RBAC 모델의 작업 기능에 대한 사용 권한을 정렬할 수 있습니다.
IAM에서는 다양한 직무에 대해 서로 다른 정책을 생성하여 RBAC를 구현합니다. 그런 다음 정책을 자격 증명(IAM 사용자, IAM 그룹 또는 IAM 역할)에 연결합니다. [가장 좋은 방법](best-practices.md)은 직무에 필요한 최소 권한을 부여하는 것입니다. 이로 인한 결과가 [최소 권한](best-practices.md#grant-least-privilege) 액세스입니다. 각 직능 정책에는 해당 정책이 할당된 자격 증명이 액세스할 수 있는 특정 리소스가 나열되어 있습니다. 기존 RBAC 모델을 사용하면 사용자가 환경에 새 리소스를 추가할 때 해당 리소스에 액세스할 수 있도록 정책을 업데이트해야 한다는 단점이 있습니다.
예를 들어, 직원이 작업 중인 세 개의 프로젝트 `Heart`, `Star` 및 `Lightning`이 있다고 가정합니다. 각 프로젝트에 대한 IAM 역할을 생성합니다. 그런 다음 각 IAM 역할에 정책을 연결하여 IAM 역할을 맡을 수 있는 모든 사람이 액세스할 수 있는 리소스를 정의합니다. 직원이 회사 내에서 직무를 변경하는 경우 다른 IAM 역할에 해당 직무를 할당합니다. 사람이나 프로그램을 둘 이상의 IAM 역할에 할당할 수 있습니다. 그러나 `Star` 프로젝트에 새 Amazon EC2 컨테이너와 같은 추가 리소스가 필요할 수 있습니다. 이 경우 `Star` IAM 역할에 연결된 정책을 업데이트하여 새 컨테이너 리소스를 지정해야 합니다. 그렇지 않으면 `Star` 프로젝트 멤버가 새 컨테이너에 액세스할 수 없습니다.
![\[이 다이어그램은 역할 기반 액세스 제어를 위해서는 각 자격 증명에 특정 직무 기반 정책을 할당해야 서로 다른 리소스에 액세스할 수 있음을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/tutorial-abac-rbac-concept-23.png)
**ABAC는 전통적인 RBAC 모델에 비해 다음과 같은 이점을 제공합니다.**
+ **ABAC 권한은 혁신적으로 확장됩니다.** 관리자가 새 리소스에 액세스할 수 있도록 기존 정책을 업데이트할 필요가 없습니다. 예를 들어, `access-project` 태그로 ABAC 전략을 설계했다고 가정합니다. 개발자는 `access-project` = `Heart` 태그와 함께 IAM 역할을 사용합니다. `Heart` 사용자에게 추가 Amazon EC2 리소스가 필요한 경우 개발자는 `access-project` = `Heart` 태그를 사용하여 새 Amazon EC2 인스턴스를 생성할 수 있습니다. 그러면 `Heart` 프로젝트의 모든 사용자가 태그 값이 일치하기 때문에 해당 인스턴스를 시작하고 중지할 수 있습니다.
+ **ABAC를 사용하면 필요한 정책 수가 적어집니다.** 각 직무에 대해 서로 다른 정책을 생성할 필요가 없기 때문에 생성해야 하는 정책이 더 적습니다. 그러므로 정책을 관리하기가 더 쉽습니다.
+ **ABAC를 사용하면 팀이 변화와 성장에 동적으로 대응할 수 있습니다.** 새 리소스에 대한 권한이 속성에 따라 자동으로 부여되므로 자격 증명에 정책을 수동으로 할당할 필요가 없습니다. 예를 들어, 회사에서 이미 ABAC를 사용하여 `Heart` 및 `Star` 프로젝트를 지원하는 경우 새 `Lightning` 프로젝트를 쉽게 추가할 수 있습니다. IAM 관리자는 `access-project` = `Lightning` 태그와 함께 새 IAM 역할을 생성합니다. 새 프로젝트를 지원하기 위해 정책을 변경할 필요는 없습니다. IAM 역할을 맡을 권한이 있는 모든 사용자는 `access-project` = `Lightning` 태그가 지정된 인스턴스를 생성하고 볼 수 있습니다. 또 다른 시나리오는 팀원이 `Heart` 프로젝트에서 `Lightning` 프로젝트로 옮기는 경우입니다. 팀원에게 `Lightning` 프로젝트에 대한 액세스 권한을 부여하기 위해 IAM 관리자는 팀원에게 다른 IAM 역할을 할당합니다. 권한 정책을 변경할 필요가 없습니다.
+ **ABAC를 사용하여 세분화된 권한을 사용할 수 있습니다.** 정책을 생성할 때는 [최소 권한을 부여](best-practices.md#grant-least-privilege)하는 것이 가장 좋습니다. 기존 RBAC를 사용하는 경우에는 특정 리소스에 대한 액세스를 허용하는 정책을 작성합니다. 그러나 ABAC를 사용하는 경우 리소스의 태그가 보안 주체의 태그와 일치하는 경우에만 모든 리소스에 대한 작업을 허용할 수 있습니다.
+ **ABAC를 사용하여 회사 디렉터리의 직원 속성을 사용합니다.** 세션 태그를 IAM에 전달하도록 SAML 또는 OIDC 공급자를 구성할 수 있습니다. 직원이 AWS에 페더레이션되면 IAM은 해당 속성을 결과 보안 주체에 적용합니다. 그런 다음 ABAC를 사용하여 이러한 속성에 따라 권한을 허용하거나 거부할 수 있습니다.
AWS에서 ABAC를 사용하는 방법을 보여 주는 자세한 자습서는 [IAM 튜토리얼: 태그를 기반으로 AWS 리소스에 액세스할 수 있는 권한 정의](tutorial_attribute-based-access-control.md) 섹션을 참조하세요.