IT STUDY LOG

[AWS] 08. 보안 본문

devops bootcamp 4/클라우드 서비스 운영

[AWS] 08. 보안

roheerumi 2023. 4. 18. 13:38

# 학습 목표

  • Cloud와 Deployment의 의미를 각각 알고, 서비스를 남에게 배포할 수 있다.
  • 클라우드 컴퓨팅이 무엇인지 설명할 수 있다.
  • 애플리케이션 배포가 어떻게 변화되어 왔는지 이해할 수 있다.
  • AWS의 각 서비스가 어떤 목적에 부합하는지 이해할 수 있다.
  • S3의 목적과, 정적 웹 사이트 배포 방법을 이해할 수 있다.
  • EC2의 주요 용어를 이해할 수 있다. (AMI, 인스턴스, 인스턴스 유형, 스토리지 타입, 퍼블릭/프라이빗 IP)
  • EC2의 인스턴스 시작/중지/종료에 대해 이해할 수 있다.
  • RDS와 EC2에서의 MySQL 사용이 어떻게 다른지 이해할 수 있다.
  • CloudFront의 목적을 이해할 수 있다.
  • Auto Scaling의 특징 및 역할을 알 수 있다.
  • 로드 밸런서 중 ELB, 그 중에서 Application Load Balancer의 목적을 이해할 수 있다.
  • AWS 인프라 중 VPC에 대해서 이해할 수 있다.
  • Route 53의 목적을 이해하고, 도메인을 연결해 HTTPS로 배포할 수 있다.
  • 빌드 및 배포시 필요한 환경 설정을 할 수 있다.
  • 배포 시 발생하는 문제를 이해하고 고칠 수 있다.

 

# 학습 내용

1.  Certificate Manager

AWS Certificate Manager

- AWS(Amazon Web Services)에서 제공하는 SSL/TLS 인증서 관리 서비스

- AWS 서비스 및 연결된 내부 리소스에 사용할 공인 및 사설 SSL/TLS(Secure Sockets Layer/전송 계층 보안) 인증서를 AWS 내에 생성, 관리, 배포, 갱신 및 모니터링

- SSL/TLS 인증서는 네트워크 통신을 보호하고 인터넷상에서 웹 사이트의 자격 증명과 프라이빗 네트워크상에서 리소스의 자격 증명을 설정하는 데 사용

- AWS Certificate Manager는 SSL/TLS 인증서를 구매, 업로드 및 갱신하는 데 드는 시간 소모적인 수동 프로세스를 대신 처리

- 이를 통해 웹 애플리케이션 및 웹사이트에서 보안 연결을 설정하고, 데이터의 기밀성과 무결성을 보호

- AWS ACM은 AWS 클라우드에서 웹사이트, 애플리케이션, API 등을 운영하는 개발자와 시스템 관리자들에게 편리하고 안전한 SSL/TLS 인증서 관리를 제공



ACM 사용 방식

1. 사용할 TLS/SSL 인증서를 AWS 계정으로 요청하거나 가져옴

2. 도메인 이름 시스템(DNS) 또는 이메일 검증을 통해 요청된 인증서의 도메인 소유권을 검증하여 인증서 발급

3. Elastic Load Balancing(ELB), Amazon CloudFront 등과 같은 다양한 AWS 서비스에서 새로 발급되거나 가져온 인증서를 사용

 

Amazon Certificate Manager 관련 레퍼런스

 

AWS Certificate Manager란 무엇입니까? - AWS Certificate Manager

AWS Certificate Manager란 무엇입니까? AWS Certificate Manager(ACM)은 AWS 웹 사이트와 애플리케이션을 보호하는 퍼블릭 및 프라이빗 SSL/TLS X.509 인증서와 키를 만들고, 저장하고, 갱신하는 복잡성을 처리합니

docs.aws.amazon.com

 

2. IAM

IAM?

- AWS Identity and Access Management

- AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스 (인증 및 접근 제어 서비스)

- AWS IAM을 사용하면 AWS 리소스에 대한 접근 권한을 관리하고, 사용자, 그룹, 역할 등을 생성하여 AWS 계정 내의 사용자와 리소스를 보호 가능

 

IAM의 기능

- 사용자 관리: AWS 계정 내에서 사용자를 생성하고, 삭제하고, 비밀번호를 관리하며, 다양한 권한을 할당

- 그룹 관리: 사용자를 그룹으로 묶어서 권한을 일괄적으로 관리

- 역할 관리: AWS 리소스에 접근하기 위한 역할을 생성하고, 필요할 때 일시적으로 역할을 부여.

- 권한 할당: IAM 정책을 사용하여 AWS 리소스에 대한 접근 권한을 세밀하게 제어

- 다단계 인증 (MFA): MFA를 활성화하여 사용자의 보안을 강화

- AWS 서비스와의 통합: AWS 서비스들과 통합하여 인증 및 접근 제어를 설정

 

IAM 자격 증명(사용자, 사용자 그룹 및 역할)

- 보안 인증 수단으로, AWS 리소스에 접근하기 위한 사용자의 신원을 확인하고 인증하는 역할을 수행

- IAM 자격 증명은 인간 사용자 또는 프로그래밍 워크로드를 대표하며, 인증된 후 AWS에서 작업을 수행할 수 있는 권한을 부여받음

- 각 IAM 자격 증명은 하나 이상의 정책과 연결 가능

- 정책은 사용자, 역할 또는 사용자 그룹 멤버가 수행할 수 있는 작업, 작업의 대상 AWS 리소스 및 작업 수행 조건을 결정

-  AWS 리소스에 대한 접근을 제어하고, 보안을 강화하기 위한 중요한 요소로 사용됨(용자는 필요한 권한을 가진 IAM 자격증명을 사용하여 AWS 리소스에 접근하고, 작업을 수행 가능)

 

IAM 자격 증명 방법

- AWS 액세스 키 (Access Key): AWS 리소스에 접근하기 위해 API나 AWS CLI(Command Line Interface)와 같은 개발자 도구를 사용할 때 사용되는 비밀 키와 공개 키의 쌍으로, 액세스 키를 사용해 AWS 리소스에 대한 접근 권한을 인증 가능

- AWS 보안 자격증명 서비스 (AWS Security Token Service, STS): AWS 리소스에 대한 일시적인 접근 권한을 부여하기 위해 사용되는 서비스로, 보안 자격증명을 생성하여 사용자에게 반환. 일시적으로 생성된 자격증명은 사전에 정의된 시간이 지나면 자동으로 만료되므로 보안성이 향상

 

IAM 사용자

AWS 계정 루트 사용자

- AWS 계정을 생성할 때 생성되는 기본적인 사용자 계정으로, 최상위 계정

- AWS 계정 내의 모든 리소스에 대한 무제한 권한을 가지며, 모든 AWS 서비스 및 리소스에 대한 접근 및 관리 권한을 가짐

- AWS 계정 루트 사용자는 AWS 리소스의 최고 관리자로 간주되어, 보안상의 위험있으므로 계정 루트 사용자의 액세스를 제한하거나 사용하지 않는 것이 권장

 

IAM 사용자

-  AWS 계정 내에서 추가로 생성할 수 있는 사용자 계정으로 계정 루트 사용자의 권한을 일부 또는 전부 위임받아 사용 가능

- IAM 사용자는 AWS 리소스에 대한 접근 권한을 가질 수 있지만, 계정 루트 사용자보다는 보다 세분화된 권한을 가진 사용자로 간주

- 권한을 더욱 세밀하게 관리하고, 사용자의 워크로드와 업무에 필요한 권한을 제한적으로 부여 가능

- IAM 사용자는 AWS CLI, AWS Management Console, AWS SDK 등 다양한 방식으로 인증하여 AWS 리소스를 관리 가능

- IAM 사용자는 단일 개인 또는 애플리케이션에 대한 특정 권한을 가지고 있는 AWS 계정 내 자격 증명

- 모범 사례로서, 가능하면 암호 및 액세스 키와 같은 장기 보안 인증 정보가 있는 IAM 사용자를 생성하는 대신 임시 보안 인증을 사용하는 것이 권장

-  IAM 사용자의 장기 보안 인증이 필요한 특정 사용 사례가 있는 경우 액세스 키 교체 권장

- 참고 :  장기 보안 인증이 필요한 사용 사례의 경우 정기적으로 액세스 키 교체

- 참고 : AWS 계정에서 IAM 사용자 생성 

 

IAM 사용자 그룹

- IAM 그룹은 IAM 사용자 컬렉션을 지정하는 자격 증명

- 그룹 로그인은 불가하나 그룹을 사용하여 여러 사용자의 권한을 한 번에 지정 가능

- 그룹을 사용하면 대규모 사용자 집합의 권한 관리 용이(ex. IAMPublishers라는 그룹을 만들어 게시 워크로드에 일반적으로 필요한 유형의 권한을 해당 그룹에 부여)

 

IAM 사용자(역할이 아님)를 생성해야 하는 경우

- 페더레이션 사용자가 지원하지 않는 사용 사례에는 IAM 사용자만 사용하는 것 권장

  • IAM 역할을 사용할 수 없는 워크로드 
  • 타사 AWS 클라이언트 – IAM Identity Center를 사용한 액세스를 지원하지 않는 도구를 사용하는 경우
  • AWS CodeCommit 액세스 – CodeCommit을 사용하여 코드를 저장하는 경우 
  • Amazon Keyspaces(Apache Cassandra용) 액세스 – IAM Identity Center 사용자를 사용할 수 없는 상황
  • 긴급 액세스 – ID 제공업체에 액세스할 수 없고 AWS 계정에 조치를 취해야 하는 상황인 경우

 

IAM 역할(Role)

- IAM 역할은 특정 권한을 가지고 있는 AWS 계정 내 ID로, AWS 리소스 간에 권한을 위임하고, 리소스에 대한 액세스를 제어하는 데 사용되는 AWS의 기능

- IAM 사용자와 유사하지만, 특정 개인과 연결되지 않고 서비스, 사용자, 그룹등에게 할당됨

- 일시적인 자격 증명을 생성해 다른 AWS 리소스에 대한 액세스 허용 가능

- 역할을 전환하여 AWS Management Console에서 IAM 역할을 임시로 수임 가능하며, AWS CLI 또는 AWS API 태스크를 호출하거나 사용자 지정 URL을 사용하여 역할을 수임 가능

- 역할 사용 방법 참고 :  IAM 역할 사용 섹션

- 임시 보안 인증이 있는 IAM 역할 사용 사례

  • 페더레이션 사용자 액세스 
  • 임시 IAM 사용자 권한 
  • 크로스 계정 액세스 
  • 교차 서비스 액세스 
    • 보안 주체 권한
    • 서비스 역할 
    • 서비스 연결 역할 
  • Amazon EC2에서 실행 중인 애플리케이션 

 

IAM 역할(사용자가 아님)를 만들어야 하는 경우

- Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행되는 애플리케이션을 생성 중이고 해당 애플리케이션이 AWS에 요청하는 경우

- 휴대폰에서 실행되는 앱을 만들고 그 앱이 AWS로 요청을 보내는 경우

- 사용자가 AWS로 페더레이션되도록 허용하고 싶은 경우

 

IAM의 임시 자격 증명

- 가장 좋은 방법은 인간 사용자와 워크로드 모두에 임시 보안 인증을 사용하는 것

- 임시 자격 증명은 기본적으로 IAM 역할에 사용되지만 다른 용도로도 사용됨

- 일반 IAM 사용자보다 제한된 권한을 갖는 임시 자격 증명을 요청 가능하며 제한된 자격 증명으로는 허용되지 않는 작업을 뜻하지 않게 수행하는 것을 방지

- 임시 자격 증명의 장점은 설정한 기간이 지나면 자동으로 만료되어 자격 증명의 유효 기간을 통제 가능

- 일시적인 자격증명은 특정 역할이나 사용자에게 부여된 권한을 사용하여 AWS 리소스에 접근할 수 있는 일정 기간 동안 유효한 자격증명

 

특징

- 유효 기간 제한: 임시 자격증명은 사용자가 정의한 유효 기간 동안에만 유효하며, 자동으로 만료 -> 보안 강화

- 권한 제어: 임시 자격증명에는 사용자가 필요한 권한을 정확하게 정의할 가능, 사용자는 IAM 정책을 사용하여 임시 자격증명에 부여할 수 있는 액세스 권한을 제어 가능

- 보안성 강화: 임시 자격증명은 임시로 생성되기 때문에 임시 자격증명을 사용하려면 실제 AWS 자격증명(예: AWS 액세스 키 및 비밀 액세스 키)을 공유하지 않아도 되며 보안을 강화하고 자격증명 노출의 위험을 감소

 

언제 IAM Identity Center 사용자를 사용할까?

-  IAM Identity Center

 > 웹 인터페이스로, AWS 계정의 IAM 사용자, 그룹, 역할 등의 관리를 위한 중앙 집중화된 대시보드

 > 사용자, 그룹, 역할의 생성, 수정, 삭제, 권한 부여, 비밀 액세스 키 관리, MFA 설정 등 IAM 리소스의 관리를 편리하게 수행할 수 있는 기능을 제공

 > AWS 관리 콘솔을 통해 접근할 수 있으며, AWS CLI, AWS SDK, AWS CloudFormation, AWS CloudTrail 등 다양한 AWS 도구를 통해 IAM 리소스를 관리 가능

- 모든 인간 사용자가 IAM Identity Center를 사용하여 AWS 리소스에 액세스하는 것 권장

- IAM Identity Center는 IAM 사용자로서 AWS 리소스에 액세스하는 것보다 훨씬 향상된 기능을 제공

  • ID 및 할당의 중앙 세트
  • 전체 AWS 조직의 계정에 대한 액세스
  • 기존 ID 제공업체에 대한 연결
  • 임시 자격 증명
  • 멀티 팩터 인증(MFA)
  • 최종 사용자를 위한 셀프 서비스 MFA 구성
  • MFA 사용의 행정 집행
  • 모든 AWS 계정 권한에 대한 Single Sign-On

- 참고 : IAM Identity Center란 무엇인가요?

 

What is IAM Identity Center? - AWS IAM Identity Center (successor to AWS Single Sign-On)

What is IAM Identity Center? With AWS IAM Identity Center (successor to AWS Single Sign-On), you can manage sign-in security for your workforce identities, also known as workforce users. IAM Identity Center provides one place where you can create or connec

docs.aws.amazon.com

 

IAM 사용자

- AWS Identity and Access Management(IAM) 사용자는 AWS에서 생성하는 엔터티

- IAM 사용자는 AWS와의 상호 작용에 IAM 사용자를 사용하는 인간 사용자 또는 서비스를 나타냄

- AWS에서 사용자는 이름과 자격 증명으로 구성(IAM 식별자)되며, 관리자 권한이 있는 IAM 사용자는 AWS 계정 루트 사용자과 같지 않음

 

AWS가 IAM 사용자를 식별하는 방법

- 사용자를 생성하면 IAM은 해당 사용자를 식별하는 다음과 같은 방법을 생성

  • IAM 사용자 생성 시 지정한 이름으로서 Richard 또는 Anaya와 같은 IAM 사용자가 "쉽게 알 수 있는 이름"(이 이름들은 AWS Management Console에서 확인 가능)
  • IAM 사용자의 Amazon 리소스 이름(ARN)으로 모든 AWS 전반에 IAM 사용자를 특별하게 식별할 필요가 있는 경우 ARN을 사용(ex. ARN을 사용하여 IAM 사용자를 Amazon S3 버킷의 IAM 정책에서 Principal로 지정 가능)
    • 예시 : arn:aws:iam::account-ID-without-hyphens:user/Richard
  • IAM 사용자의 고유 식별자. 이 ID는 IAM 사용자를 생성하기 위해 API, Tools for Windows PowerShell 또는 AWS CLI를 사용할 때만 반환되며 콘솔에서는 이 ID를 볼 수 없음 (참고 : IAM 식별자)

 

IAM 사용자 및 보안 인증

IAM 사용자 보안 인증 유형

- AWS Management Console을 사용하여 IAM 사용자를 생성할 때 최소한 콘솔 암호 또는 액세스 키를 포함하도록 선택해야 함

- 기본적으로 AWS CLI 또는 AWS API를 사용하여 새로 생성된 IAM 사용자는 어떤 종류의 자격 증명도 보유하지 않음

-사용자의 사용 사례를 기반으로 IAM 사용자의 보안 인증 유형을 생성해야 함

 

암호, 액세스 키 및 다중 인증(MFA) 디바이스 관리 옵션

 

IAM 사용자 및 권한

- 기본적으로 새로운 IAM 사용자는 작업을 수행할 어떠한 권한도 없음

- 개별 IAM 사용자를 두면 각 사용자에게 개별적으로 권한을 할당할 수 있다는 장점

- 사용자 몇 명에게 관리 권한을 할당하면 이들이 AWS 리소스를 관리하고 다른 IAM 사용자까지 생성하고 관리 가능

- 대부분의 경우 사용자의 업무에 필요한 작업(AWS 작업) 및 리소스로만 사용자의 권한을 제한

 > 사용자를 생성하여 초기 자격 증명과 권한을 부여하는 절차 :  AWS 계정에서 IAM 사용자 생성

 > 기존 사용자에 대한 권한을 변경하는 절차 :  IAM 사용자의 권한 변경

 > 사용자의 암호나 액세스 키를 변경하는 절차 :  AWS에서 사용자 암호 관리, IAM 사용자의 액세스 키 관리 섹션

- IAM 사용자에게 권한 경계를 추가 가능 : IAM의 정책 및 권한 섹션

 

IAM 사용자 및 계정

- 각 IAM 사용자는 오직 한 개의 AWS 계정과만 연결

- IAM 사용자는 AWS 계정 내에서 정의되고 계정에 속한 IAM 사용자가 수행하는 모든 AWS 활동은 해당 계정으로 청구

- AWS 계정의 IAM 리소스 수와 크기는 제한됨 (참고: IAM 및 AWS STS 할당량, 이름 요구 사항 및 문자 제한)

 

서비스 계정인 IAM 사용자

- IAM 사용자는 연결된 자격 증명 및 권한을 지닌 IAM의 리소스

- IAM 사용자는 자격 증명을 사용하여 AWS에 요청하는 사용자 또는 애플리케이션을 나타낼 수 있으며, 이를 일반적으로 서비스 계정이라 칭함

- 애플리케이션에서 IAM 사용자의 장기 자격 증명을 사용하기로 선택한 경우 액세스 키를 애플리케이션 코드에 직접 포함하지 말 것

- AWS SDK 및 AWS Command Line Interface를 사용하면 코드에서 유지할 필요가 없도록 알려진 위치에 액세스 키를 추가 가능

 > 적절하게 IAM 사용자 액세스 키 관리

 > 장기 액세스 키 대신 임시 보안 자격 증명(IAM 역할)을 사용

 

 

IAM 사용자 그룹

- IAM 사용자의 집합

- 사용자 그룹을 활용하면 다수의 사용자들에 대한 권한을 지정함으로써 해당 사용자들에 대한 권한을 더 쉽게 관리 가능

- 사용자 그룹의 모든 사용자가 정책의 권한을 받도록 아이덴티티 기반 정책을 사용자 그룹에 연결 가능

- 그룹은 인증이 아니라 권한과 관련이 있고 보안 주체는 인증된 IAM 엔터티이기 때문에 정책(예: 리소스 기반 정책)에서 사용자 그룹을 Principal로 식별 불가 (참고: 자격 증명 기반 정책 및 리소스 기반 정책)

 

사용자 그룹 특징

  • 한 사용자 그룹에 여러 사용자가 포함될 수 있으며 한 사용자가 다중 사용자 그룹에 속할 수 있음
  • 사용자 그룹은 중첩될 수 없음 (사용자 그룹은 사용자만 포함할 수 있으며 다른 그룹은 포함 불가)
  • AWS 계정의 모든 사용자를 자동으로 포함하는 기본 사용자 그룹 없음(이러한 사용자 그룹이 필요한 경우 하나 만들어 새로운 사용자를 각각 해당 그룹에 할당해야 함)
  • 그룹 수, 사용자가 멤버가 될 수 있는 그룹 수와 같이 AWS 계정에 있는 IAM 리소스의 수와 크기는 제한(참고: IAM 및 AWS STS 할당량, 이름 요구 사항 및 문자 제한)
 

 

IAM 역할 용어 및 개념

역할

- 계정에서 생성할 수 있는 특정 권한을 가진 IAM 자격 증명

- 사용자와의 공통점과 차이점

 > 공통점 : 역할과 사용자 모두 AWS에서 자격 증명으로 할 수 있는 것과 할 수 없는 것을 결정하는 권한 정책을 포함하는 AWS 자격 증명

 > 차이점 : 역할은 한 사람과만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있음 / 역할에는 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없고 역할을 맡은 사람에게는 해당 역할 세션을 위한 임시 보안 자격 증명이 제공

 

역할 사용 주체

- 역할과 동일한 AWS 계정의 IAM 사용자

- 역할과 다른 AWS 계정의 IAM 사용자

- AWS에서 제공하는 웹 서비스(예: Amazon Elastic Compute Cloud(Amazon EC2))

- SAML 2.0, OpenID Connect 또는 사용자 지정 구축 자격 증명 브로커와 호환되는 외부 자격 증명 공급자(IdP) 서비스에 의해 인증된 외부 사용자

 

AWS 서비스 역할

- 서비스 역할은 서비스가 사용자를 대신하여 작업을 수행하기 위해 수임하는 IAM 역할

- 참고 :  AWS 서비스에 대한 권한을 위임할 역할 생성

 

EC2 인스턴스의 AWS 서비스 역할

- Amazon EC2 인스턴스에서 실행 중인 애플리케이션이 계정에서 작업을 수행하기 위해 수임할 수 있는 특수한 유형의 서비스 역할

- 시작된 EC2 인스턴스에 할당

- 해당 인스턴스에서 실행 중인 애플리케이션은 임시 보안 자격 증명을 검색하고 역할이 허용하는 작업을 수행 가능

- 참고: IAM 역할을 사용하여 Amazon EC2 인스턴스에서 실행되는 애플리케이션에 권한 부여

 

AWS 서비스 연결 역할

-  서비스는 사용자를 대신하여 작업을 수행하기 위해 역할을 수임 가능

- 서비스 연결 역할은 AWS 계정에 나타나고, 서비스가 소유

- IAM 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집은 불가

- 참고 :  AWS IAM으로 작업하는 서비스, 서비스 연결 역할 사용 

 

역할 함께 묶기

- 역할 체인은 역할을 사용하여 AWS CLI 또는 API를 통해 두 번째 역할을 수임하는 경우 (ex) RoleA에 RoleB를 수임할 권한

- 역할을 맡을 때 세션 태그를 전달하고 태그를 전이적으로 설정 가능(전이적 세션 태그 참고: AWS STS에서 세션 태그 전달)

- 역할 체인을 사용시 AWS CLI 또는 AWS API 역할 세션이 최대 1시간으로 제한

 > AssumeRole API 작업을 사용하여 역할을 수임할 때 DurationSeconds 파라미터를 사용하여 역할 세션 길이를 지정 가능

 > 역할에 대한 최대 세션 기간 설정에 따라 파라미터 값을 최대 43200초(12시간)까지 지정 가능

 > but, 역할 함께 묶기를 사용해 역할을 수임하고 1시간보다 큰 DurationSeconds 파라미터 값을 지정하면 작업이 실패

- AWS에서는 역할을 사용하여 EC2 인스턴스에서 실행되는 애플리케이션에 권한을 부여하는 것을 역할 함께 묶기로 간주하지 않음

 

위임

- 제어하는 리소스에 대한 액세스를 허용하는 권한을 누군가에게 부여하는 것

- 위임은 두 계정 간에 신뢰를 설정하는 것을 포함합

 > 첫 번째: 리소스를 소유한 계정(신뢰하는 계정)

 > 두 번째: 리소스에 액세스해야 하는 사용자가 포함된 계정입니다(신뢰되는 계정)

 

신뢰받는 계정과 신뢰하는 계정

  • 동일 계정
  • 조직에서 통제하는 별도의 계정
  • 서로 다른 조직이 소유한 2개의 계정

- 리소스에 액세스할 수 있는 권한을 위임하려면 두 개의 정책이 연결된 신뢰하는 계정에서 IAM 역할을 생성

- "권한 정책"은 역할 사용자에게 리소스에 대해 의도한 작업을 수행하는 데 필요한 권한을 부여하며, "신뢰 정책"은 역할을 위임하도록 허용된 신뢰할 수 있는 계정 멤버를 지정

- 신뢰 정책을 생성할 때 와일드카드(*)를 보안 주체로 지정할 수 없음

- 신뢰 정책의 권한 절반 : 신뢰하는 계정의 역할에 연결, 나머지 절반: 사용자에게 역할 전환 또는 위임을 허용하는 신뢰받는 계정의 사용자에게 연결된 권한 정책

- 임시로 역할을 위임하는 사용자는 자신의 고유 권한을 포기하고 대신 해당 역할의 권한을 위임

- 사용자가 역할을 끝내거나 역할 사용을 중지하면 원래 사용자 권한이 자동으로 회복됨.

- 외부 ID라 불리는 부가적인 파라미터는 동일한 조직에 의해 제어되지 않는 계정 사이에서 역할을 안전하게 사용하도록 하는 데 도움

 

연동

- 외부 자격 증명 공급자와 AWS 사이에 신뢰 관계를 생성하는 것

- 사용자는 Login with Amazon, Facebook, Google 또는 OpenID Connect(OIDC)와 호환되는 IdP 등의 웹 자격 증명 공급자에 로그인 가능

- 또한, 사용자는 Microsoft Active Directory 연동 서비스와 같은 Security Assertion Markup Language(SAML) 2.0과 호환되는 엔터프라이즈 자격 증명 시스템에 로그인 가능

- OIDC 및 SAML 2.0을 사용해 이 외부 자격 증명 공급자와 AWS 사이에 신뢰 관계를 구성하면 사용자가 IAM 역할에 할당됨

- 사용자는 임시 보안 자격 증명을 부여받아 AWS 리소스에 대한 액세스가 가능

 

페더레이션 사용자

- 페더렐이션 사용자 : IAM 사용자를 생성하는 대신 AWS Directory Service, 엔터프라이즈 사용자 디렉터리 또는 웹 자격 증명 공급자의 기존 자격 증명을 사용하는 사용자

- AWS에서는 자격 증명 공급자를 통해 액세스가 요청되면 페더레이션 사용자에게 역할을 할당

- 페더레이션 사용자 참고 :  IAM 사용 설명서의 페더레이션 사용자 및 역할

 

신뢰 정책

- 역할을 수임하도록 신뢰하는 보안 주체를 정의하는 JSON 정책 문서

- 역할 신뢰 정책은 IAM의 역할에 연결된 필수 리소스 기반 정책

- 신뢰 정책에서 지정할 수 있는 보안 주체에는 사용자, 역할, 계정 및 서비스가 포함

 

권한 정책

- JSON 형식의 권한 문서로, 역할이 사용할 수 있는 리소스와 작업을 정의

- 이 문서는 IAM 정책 언어의 규칙에 따라 작성

 

권한 경계

- 자격 증명 기반 정책이 역할에 부여할 수 있는 최대 권한을 제한하는 정책을 사용하는 고급 기능

- 서비스 연결 역할에 권한 경계를 적용할 수 없음 (참고: IAM 엔터티의 권한 범위)

 

보안 주체

- 작업을 수행하고 리소스에 액세스할 수 있는 AWS의 개체로 AWS 계정 루트 사용자, IAM 사용자

- 역할리소스에 액세스할 수 있는 권한을 다음 두 가지 중 한 가지 방식으로 부여 가능

  • 권한 정책을 사용자에게(직접 또는 그룹을 통해 간접적으로) 또는 역할에게 연결
  • 리소스 기반 정책을 지원하는 서비스의 경우 해당 리소스에 연결된 정책의 Principal 요소에서 보안 주체를 식별

- AWS 계정을 보안 주체로 참조하는 경우 그 보안 주체는 일반적으로 해당 계정 내에서 정의된 모든 보안 주체를 의미

- 역할의 신뢰 정책에서 Principal 요소에 와일드카드(*)를 사용 불가

 

크로스 계정 액세스를 위한 역할

- 한 계정의 리소스에 대한 액세스 권한을 다른 계정의 신뢰할 수 있는 보안 주체에 부여하는 역할.

- 역할은 크로스 계정 액세스를 부여하는 기본적인 방법

- 리스스 기반 정책 : 일부 AWS 제품을 사용 시 (역할을 프록시로 사용하는 대신) 리소스에 직접 정책을 연결 가능. 이 정책을 사용하여 다른 AWS 계정의 보안 주체에게 리소스에 대한 액세스 권한을 부여 가능

- 리소스 종류: Amazon Simple Storage Service(S3) 버킷, S3 Glacier 볼트, Amazon Simple Notification Service(SNS) 주제 및 Amazon Simple Queue Service(SQS) 대기열 등

- 리소스 기반 정책을 지원하는 서비스: AWS IAM으로 작업하는 서비스 

- 리소스 기반 정책: IAM 역할과 리소스 기반 정책의 차이 

 

AWS 서비스에 대한 액세스 권한 제공

많은 AWS 서비스에서는 역할을 사용하여 해당 서비스가 액세스할 수 있는 대상을 제어해야 합니다. 서비스가 사용자를 대신하여 작업을 수행하기 위해 수임한 역할을 서비스 역할이라고 합니다. 역할이 서비스에 대해 특수한 목적을 수행하는 경우 EC2 인스턴스의 서비스 역할 또는 서비스 연결 역할로 분류할 수 있습니다. 서비스에서 역할을 사용하는지 여부와 서비스에서 사용할 역할을 할당하는 방법을 알아보려면 서비스별 AWS 문서를 참조하세요.

역할을 생성해 AWS가 제공하는 서비스에 액세스 권한을 위임하는 것에 대한 자세한 내용은 AWS 서비스에 대한 권한을 위임할 역할 생성 섹션을 참조하세요.

 

IAM의 정책 및 권한

JSON 정책 개요

- 대부분의 정책은 AWS에 JSON 문서로서 저장

- AWS Management Console의 시각적 편집기를 사용하면 JSON을 사용하지 않고 고객 관리형 정책을 생성하고 편집 가능

- but, 그룹 또는 복잡한 정책에 대해 인라인 정책을 사용하는 경우에는 콘솔을 사용하여 JSON 편집기에서 해당 정책을 생성하고 편집해야 함

- IAM: JSON 구문 오류를 식별 가능(IAM 정책 검증)

- IAM Access Analyzer: 정책을 더욱 구체화하는 데 도움이 되는 권장 사항과 함께 추가 정책 검사를 제공(IAM Access Analyzer 정책 검증)

 

JSON 정책 문서 구조 (IAM JSON 정책 요소 참조)

  • 문서 상단에 위치하는 정책 전반의 선택적 정보
  • 하나 이상의 개별 문
  • Version - 사용하고자 하는 정책 언어의 버전을 지정하며 최신 2012-10-17 버전을 사용 권장(참고:IAM JSON 정책 요소: Version)
  • Statement - 이 주요 정책 요소를 다음 요소의 컨테이너로 사용하며 정책에 설명문 둘 이상을 포함 가능
  • Sid(선택 사항) - 선택 설명문 ID를 포함하여 설명문들을 구분
  • Effect - Allow 또는 Deny를 사용하여 정책에서 액세스를 허용하는지 또는 거부하는지 여부를 설명
  • Principal(일부 상황에서만 필요) - 리소스 기반 정책을 생성하는 경우 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 페더레이션 사용자를 표시, 사용자 또는 역할에 연결할 IAM 권한 정책을 생성 시에는 불가. 보안 주체는 사용자 또는 역할을 의미
  • Action - 정책이 허용하거나 거부하는 작업 목록을 포함
  • Resource(일부 상황에서만 필요) - IAM 권한 정책을 생성하는 경우 작업이 적용되는 리소스 목록을 지정해야 합니다. 리소스 기반 정책을 생성하는 경우 이 요소는 선택 사항으로 이 요소를 포함하지 않으면 작업이 적용되는 리소스는 정책이 연결된 리소스
  • Condition(선택 사항) - 정책에서 권한을 부여하는 상황을 지정

 

복수의 문 및 복수의 정책

- 엔터티(사용자 또는 역할)에 부여할 권한을 하나 이상 정의하고자 할 경우, 단일 정책에 여러 설명문 사용이나 여러 정책을 연결 가능

- 단일한 설명문에 여러 권한을 정의하려고 할 경우 정책이 기대하는 액세스를 보장하지 않을 수 있으므로 리소스 유형에 따라 정책을 나누는 것이 권장

- 정책의 제한된 크기로 더 복잡한 권한에 대해서는 여러 정책을 사용해야 할 수 있으므로 개별 사용자 관리형 정책에 권한의 기능적 그룹화를 만드는 방법 권장 (ex. IAM 사용자 관리용 정책 하나, 자기 관리용 하나 및 S3 버킷 관리용 기타 정책 하나를 생성. 여러 설명문과 여러 정책의 조합과 상관없이 AWS는 동일한 방식으로 정책을 평가) 

- 예시 : 다음 정책에는 설명문이 세 개 있으며 각 설명문은 단일 계정에 별도의 권한 세트를 부여

  • Sid의 FirstStatement: 사용자가 자체 암호를 변경하도록 허용. 이 문에서 Resource 요소는 “*”(“모든 리소스”를 의미)이지만 실제로 ChangePassword API 작업(또는 동등한 change-password CLI 명령)은 요청을 수행한 사용자의 암호에만 영향을 미침.
  • Sid의 SecondStatement: 사용자가 자신의 AWS 계정에 있는 모든 Amazon S3 버킷을 나열 허용. 이 문에서 Resource 요소는 "*"("모든 리소스"를 의미)이지만 정책에서 다른 계정의 리소스에 대한 액세스 권한을 부여하지 않으므로 사용자는 자신의 AWS 계정에 있는 버킷만 나열 가능
  • Sid의 ThirdStatement: 사용자가 confidential-data라는 버킷에 있는 객체를 나열 및 검색할 수 있도록 하지만, 이는 사용자가 멀티 팩터 인증(MFA)에서 인증한 경우에 한함, 정책의 Condition 요소는 MFA 인증을 수행
  • 정책 문에 Condition 요소가 포함된 경우: Condition 요소가 true로 평가된 경우에만 해당 문이 유효
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FirstStatement",
      "Effect": "Allow",
      "Action": ["iam:ChangePassword"],
      "Resource": "*"
    },
    {
      "Sid": "SecondStatement",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Sid": "ThirdStatement",
      "Effect": "Allow",
      "Action": [
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": [
        "arn:aws:s3:::confidential-data",
        "arn:aws:s3:::confidential-data/*"
      ],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

 

최소 권한 부여

- IAM 정책을 생성할 때는 최소 권한 부여의 표준 보안 조언을 따르거나, 작업 수행에 필요한 최소한의 권한만 부여

- 최소한의 권한 조합으로 시작하여 필요에 따라 추가 권한을 부여하길 권장

- 최소 권한의 대안으로 AWS 관리형 정책 또는 와일드카드(*)를 사용하는 정책 권한을 사용하여 정책을 시작 가능 

 

IAM에서는 부여하는 권한을 구체화하는 데 도움이 되는 몇 가지 옵션

 

기타 참고 레퍼런스


 

IAM의 보안 모범 사례

임시 보안 인증을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 공급자와의 페더레이션을 사용하도록 요구

- AWS에 액세스할 때 인간 사용자에게 임시 보안 인증을 사용하도록 요구

- 임시 보안 인증을 제공하는 역할을 가정하여 인간 사용자가 AWS 계정에 페더레이션 액세스를 제공하도록 ID 공급자를 사용 가능

- 중앙 액세스 관리를 위해 AWS IAM Identity Center (successor to AWS Single Sign-On)(IAM Identity Center)를 사용하여 계정에 대한 액세스 권한과 해당 계정 내 권한을 관리 권장

- IAM Identity Center를 사용하여 사용자 자격 증명을 관리하거나 외부 자격 증명 공급자의 IAM Identity Center에서 사용자 자격 증명에 대한 액세스 권한을 관리가능(참고: AWS IAM Identity Center (successor to AWS Single Sign-On)란 무엇입니까?)

 

AWS에 액세스하려면 워크로드에 IAM 역할이 있는 임시 자격 증명을 사용하도록 요구

- 워크로드: 애플리케이션이나 백엔드 프로세스같이 비즈니스 가치를 창출하는 리소스 및 코드 모음

- 워크로드에 액세스 권한이 필요한 사용자를 위해 IAM 역할 사용(참고: AWS Identity and Access Management Roles Anywhere, 튜토리얼: IAM 역할을 사용한 AWS 계정 간 액세스 권한 위임)

 

다중 인증(MFA) 필요

- 역할을 사용하는 것을 권장하나 계정에 IAM 사용자 또는 루트 사용자가 필요한 시나리오의 경우 추가 보안을 위해 MFA가 필요

- MFA에는 인증 문제에 응답을 생성하는 디바이스 존재(AWS에서 멀티 팩터 인증(MFA) 사용)

- IAM Identity Center의 MFA: 다중 인증

 

장기 보안 인증이 필요한 사용 사례의 경우 정기적으로 액세스 키 교체

- 프로그래밍 방식 액세스 권한과 장기 보안 인증이 있는 IAM 사용자가 필요한 시나리오의 경우 액세스 키를 교체하는 것 권장

- 참고 :  액세스 키 교체을 참조하세요.

 

AWS에서 IAM 사용자의 장기 보안 인증이 필요한 특정 사용 사례

 

루트 사용자 보안 인증을 보호하고 일상적인 작업에 사용하지 말 것

- 루트 사용자에 대한 액세스 키는 결제 정보를 비롯하여 모든 AWS 서비스에 대한 리소스 전체에 대한 액세스 권한을 부여하기 때문에 액세스 키 생성은 권장하지 않음

- 일상적인 작업에 루트 사용자를 사용하지 말 것

- 루트 사용자는 루트 사용자만 수행할 수 있는 작업을 완료하는 데 사용합니다

- 루트 사용자로 로그인해야 하는 태스크의 전체 목록: 루트 사용자 보안 인증이 필요한 태스크

- 추가 모범 사례: AWS Account Management 사용 설명서의 Best practices to protect your account's root user(계정의 루트 사용자를 보호하기 위한 모범 사례)

 

최소 권한 적용

- IAM 정책을 사용하여 권한을 설정하는 경우 작업을 수행하는 데 필요한 권한만 부여

- IAM을 사용하여 권한 적용 참고 : IAM의 정책 및 권한

 

AWS 관리형 정책으로 시작하고 최소 권한 지향

- 사용자 및 워크로드에 권한 부여를 시작하려면 많은 일반 사용 사례에 대한 권한을 부여하는 AWS 관리형 정책을 사용

- AWS 관리형 정책은 모든 AWS 고객이 사용할 수 있기 때문에 특정 사용 사례에 대해 최소 권한을 부여하지 않을 수 있음

- 따라서 사용 사례에 고유한 고객 관리형 정책을 정의하여 권한을 줄이는 것이 권장

- 참고 : AWS 관리형 정책 , 직무에 관한 AWS 관리형 정책 

 

IAM 액세스 분석기를 사용하여 액세스 활동을 기반으로 최소 권한 정책 생성

- 작업을 수행하는 데 필요한 권한만 부여하기 위해 AWS CloudTrail에 로깅된 액세스 활동에 따라 정책을 생성 가능

- IAM Access Analyzer는 IAM 역할이 사용하는 서비스와 작업을 분석한 다음 사용할 수 있는 세분화된 정책을 생성

- 정책 생성에 대한 자세한 내용: IAM Access Analyzer 정책 생성

 

사용하지 않는 사용자, 역할, 권한, 정책 및 보안 인증은 정기적으로 검토하고 제거

- IAM에서는 마지막으로 액세스한 정보를 제공하여 더 이상 필요하지 않은 사용자, 역할, 권한, 정책 및 자격 증명을 식별하여 제거할 수 있도록 지원

- 자세한 내용: 마지막으로 액세스한 정보를 사용하여 AWS에서의 권한 재정의 

 

IAM 정책의 조건을 사용하여 액세스 추가 제한

- 정책 명령문 적용 조건을 지정 가능

-  작업 및 리소스에 대한 액세스 권한을 부여할 수 있지만 액세스 요청이 특정 조건을 충족하는 경우에만 가능

- 자세한 내용: IAM JSON 정책 요소: Condition

 

IAM Access Analyzer를 사용하여 리소스에 대한 퍼블릭 및 크로스 계정 액세스 확인

- AWS에서 퍼블릭 또는 크로스 계정 액세스에 대한 권한을 부여하기 전에 해당 액세스 권한이 필요한지 여부를 확인할 것

- IAM Access Analyzer를 사용해 지원되는 리소스 유형에 대한 퍼블릭 및 크로스 계정 액세스를 미리 보고 분석 가능

- 자세한 내용: IAM Access Analyzer API를 사용하여 액세스 미리 보기

 

IAM Access Analyzer를 사용하여 IAM 정책을 검증하여 안전하고 기능적인 권한을 보장

- 생성한 정책을 검증하여 IAM 정책 언어(JSON) 및 IAM 모범 사례를 준수하는지 확인

- IAM Access Analyzer 정책 검증을 사용하여 정책을 검증 가능

- 자세한 내용: IAM Access Analyzer 정책 검증, IAM Access Analyzer 정책 확인 참조

 

여러 계정에 권한 가드레일 설정

- 워크로드를 확장할 때 AWS Organizations에서 관리하는 여러 계정을 사용하여 워크로드를 분리

- Organizations 서비스 제어 정책(SCP)을 사용하여 계정 전체의 모든 IAM 사용자 및 역할에 대한 액세스를 제어하는 권한 가드레일을 설정

- SCP는 AWS 조직, OU 또는 계정 수준에서 조직의 권한을 관리하는 데 사용할 수 있는 조직 정책 유형

- 설정한 권한 가드레일은 해당 계정 내의 모든 사용자 및 역할에 적용

- but, SCP만으로는 조직 내 계정에 권한을 부여하기에 충분하지 않으므로 관리자는 실제로 권한을 부여하기 위해 여전히 자격 증명 기반 또는 리소스 기반 정책을 IAM 사용자, IAM 역할 또는 계정의 리소스에 연결할 필요성(참고: AWS Organizations, 계정 및 IAM 가드레일)

 

권한 경계를 사용하여 계정 내에서 권한 관리 위임

- 다른 사람에게 권한을 위임하는 경우 권한 경계를 사용하여 위임하는 최대 권한을 설정

- 권한 경계는 관리형 정책을 사용하여 자격 증명 기반 정책을 통해 IAM 역할에 부여할 수 있는 최대 권한을 설정하는 고급 기능

- 권한 경계는 자신에게는 권한을 부여하지 않음

- 자세한 내용: IAM 엔터티의 권한 범위

 

# References

- 챗 GPT

저작자표시 비영리 변경금지

'devops bootcamp 4 > 클라우드 서비스 운영' 카테고리의 다른 글

[지속적 통합] 01. CI/CD 리뷰  (0) 2023.04.20
[AWS] 09. 컨테이너 배포  (1) 2023.04.19
[AWS] 08. 서비스 노출  (0) 2023.04.17
[AWS] 07. 수평확장  (0) 2023.04.17
[AWS] 06. VPC  (0) 2023.04.17
'devops bootcamp 4/클라우드 서비스 운영' Related Articles more
Comments