AWS 온라인 컨퍼런스 정리3

[ AWS IAM과 친해지기 ]

 

AWS 사용 시작

AWS 서비스 사용 - 계정 생성

Account Owner ID (Root Account) : 계정을 만드실 때 사용한 이메일 계정

 - 구독한 모든 서비스에 대한 접근

 - 과금 정보에 대한 접근

 - 콘솔 및 API 사용

 - 기술 지원 계약 변경

 

IAM 사용자, 역할, Federated 사용자

 - 지정된 일부 서비스에 대한 접근

 - 콘솔 및 API tkdyd

 - 기술 지원 요청

 

어플리케이션을 위한 임시 보안 자격 증명

 - 지정된 일부 서비스에 대한 접근

 - 콘솔 및 API 사용

 

루트 어카운트는 AWS 모든 서비스에 대한 접근 권한을 가지고 있기 때문에 어플리케이션 혹인 일반적은 관리 업무에도 사용하는 것을 권고드리지 않습니다.

초기에 작업을 하실 때 몇 가지 중요한 작업이 끝나시면 가급적 사용하지 않으시는 걸 권고를 드립니다.

루트 대신 IAM을 이용해서 작업을 하시면 되는데 IAM은 사용자, 역할 그리고 Federation과 같은 기능을 제공합니다.

이와 같은 기능을 이용해서 콘솔 혹은 CLI로 AWS 사용이 가능합니다.

보다 강력한 보안을 원하신다면 임시 보안자격증명을 사용하실 수 있습니다.

 

IAM 사용자로 콘솔을 사용하시거나 IAM 사용자로 Access Key 페어로 CLI를 사용하시는 것은 영구 자격증명으로 사용자가 새로 비밀번호나 Access Key 페어를 재발급받기 전까지 계속 사용할 수 있습니다.

따라서 자격증명정보 유출 시, 보안적인 문제가 발생할 수 있습니다.

하지만 임시 보안자격증명은 시간제한이 있는 세션토큰이 발급되며, 이는 만료기한이 정해져 있습니다.

기한 만료 후에는 토큰을 재발급 받아야 다시 AWS API에 연결할 수 있기 때문에 영구 자격증명을 사용하시는 것보다 보안이 강화됩니다.

 

AWS 서비스 사용 - Console 기반 작업 

 - 가장 단순하고 쉽다라는 장점이 있다.

 - 반복작업이나 대량 작업을 하기에는 적합하지 않다.

 - 시간이 오래 걸린다.

 

따라서 모든 작업을 콘솔에서 하는 것은 비효율적일 수 있다.

 

AWS 서비스 사용 - Script 기반 작업

 - 반복 작업에 적합하다.

 - 원하는 항목에 대한 수정이 용이하다.

 - 리소스의 준비 상태 확인이 어렵다.

 - 문제 발생 시 복원이 어렵다.

 

AWS 서비스 사용 - 프로비저닝 엔진 사용

 - 자동화 구현에 용이하다.

 - 반복 작업에 적합하다.

 - 에러 발생 시 원복이 쉽다.

 - 최초 구현이 복잡하다.

 

Infra as a code : 인프라를 코드로 관리하는 방법론

AWS CloudFormation 혹은 오픈소스 Terraform을 이용해서 원하는 환경을 정의하고 이에 따라 환경을 자동으로 배포하거나 복제하는 방법을 사용할 수도 있습니다.

 

AWS 서비스 사용 - CDK 사용

 - 코드 기반

 - 원하는 형상에 대한 정의

 - 초기 코딩의 복잡성

 

내가 원하는 언어를 가지고 형상관리를 할 수 있다.

AWS에서는 Cloud Development Kit이라는 이름으로 이런 방식을 지원하고 있다.

타입스크립트, JavaScript, Python, Java, C#을 지원하며 익숙한 프로그래밍 언어로 AWS인프라를 관리할 수 있게 된다.

 

결국 중요한건 API (Everything API)

클라이언트가 AWS 리소스에 보내는 모든 조회/업데이트/생성/삭제 요청은 모두 API로 이루어지게 됩니다.

그리고 AWS 자원들 끼리 주고받는 요청과 응답도 모두 API 형태를 띄고 있습니다.

 

AWS에서 API 인증(Signature)

API를 보호하기 위해서 AWS는 Signature를 사용하고 있습니다.

 - DynamoDB에 대한 ListTables API에 HTTP header 값 입니다.

POST /API-Request HTTP/1.1
Host: any-aws-services.us-east-1.amazonaws.com
X-Amz-Date: 2190418T123600Z
Content-Type: application/x-www-form-urlencoded
Authorization: AWS4-HMAC-SHA256
Credential=ASIAXXXXXXXX/20181126/us-east-1/sqs/aws4_request,SignedHeaders=content-type;host;x-amz-data,Signature=b97dfa904a5beff61c982a1b6f458b799221646efd99d3219ec94cdf2500

Credential=ASIAXXXXXXXX : Access Key ID로 요청 주체(IAM principal)를 인증

Signature=b97dfa904a5beff61c982a1b6f458b799221646efd99d3219ec94cdf2500 : 비밀키로 생성한 HMAC 서명값(Sig v4) 검증

 

기본적으로 모든  AWS API는 자격 증명이 포함이 되어 있는데, AWS에서의 기본 자격 증명은 Access Key ID 그리고 Secret Key 조합으로 이루어져 있습니다.

Access Key ID가 표시되고, Secret Key와 같은 경우는 노출이 되면 안되기 떄문에 Secret Key를 가진 사람만 생성할 수 있는 HMAC 서명 값을 포함하게 됩니다.

여기에 IAM Role과 같이 임시 Credential를 쓰는 경우에는 Session Token이 추가 됩니다.

결과적으로 요청이 DynamoDB에 도착하면 AWS는 요청 내용과 비교를 해서 이 서명값을 확인하고 해당 타임스탬프와 같은 것들을 확인하고 결정적으로 이 Credential이 적절한 권한을 갖고 있는 지 판단을 해서 허용의 여부를 결정짓게 됩니다.

 

AWS API를 직접 HTTP 방식으로 호출하실 때는 위와 같이, 프로그래밍적 방식으로 접근하신다면 아래와 같이 하실 수도 있습니다.

 - Signature 생성 코드 예제 (Python)

def sign(key, msg): 
	return hmac.new(key, msg.encode("utf-8"), hashlib.sha256).digest()

def getSignatureKey(key, dateStamp, regionName, serviceName):
	kDate = sign(("AWS4" + key).encode("utf-8"), dateStamp)
	kRegion = sign(kDate, regionName)
	kService = sign(kRegion, serviceName)
	kSigning = sign(kService, "aws4_request")
	return kSigning

 추가적으로 AWS SDK를 쓰신다면 SDK가 여러분들을 위해 해당 작업을 해주기 때문에 별도 Signature 생성 로직 구현이 필요 없어집니다.

 

AWS Identity and Access Management

AWS Identity and Access Management (IAM)

AWS IAM은 AWS 전반에 걸쳐 권한을 통제하는 서비스 입니다.

일반적으로 접근 제어에 대한 이야기를 할 때 인증과 인가를 나눠서 설명을 하는데,

인증은 클라이언트가 자신이 주장하는 사용자와 같은 사용자 인지를 확인하는 과정이고,

인가는 클라이언트가 하고자 하는 작업이 해당 클라이언트에게 허가된 작업인지를 확인하는 권한 부여 과정입니다.

 

IAM은 Identity and Access Management로 

Identity는 AWS로 요청을 할 수 있는 보안주체(Principal)를 AWS 어카운트 내에 만들어주는 역할을 하고,

Access Management는 어떤 보안주체, 어떤 리소스에 대해 어떤 권한을 가지는지 정의하는 도구로 동작하게 됩니다.

 

I is for Identity : 실 사용자 -> IAM 사용자(USER)

AWS계정을 생성한 고객은 기본적으로 계정을 생성할 때 사용한 이메일 계정과 동일한 루트 유저를 가지고 있게 됩니다.

하지만 루트 유저는 너무 많은 권한을 보유하고 있고, 권한을 제어할 수 없는 슈퍼 유저이기 때문에 보안상 자유롭게 사용하기는 굉장히 취약한 계정이기도 합니다.

따라서 루트 어카운트보단 IAM User를 만드시고 루트 어카운트는 가급적 사용하지 않으시는 것을 권장드립니다.

 

IAM 사용자는 두 가지 AWS 접근 유형을 가집니다.

하나는 유저네임 그리고 패스워드를 입력하고 콘솔에 로그인을 할 때 사용하는 접근유형,

그리고 또 하나는 AWS API 요청을 할 떄 Access Key와 Secret Key로 구성된 Credential를 포함해서 인증을 받는 유형으로,

둘 다 장기 Credential를 이용해서 서비스에 접근을 하는 보안 주체입니다.

 

I is for Identity : AWS IAM Role(역할)

 - 정의된 권한 범위 내 AWS API를 사용할 수 있는 임시 자격 증명

 - IAM Role를 사용하면 사용자 권한을 공유하거나 매번 필요한 권한 부여 불필요

 

I is for Identity : 인스턴스/타서비스 -> IAM role

EC2가 확장을 위해 Auto Scaling에 접근해서 상호 작용을 한다든지, Lambda가 S3에 접근을 해서 특정 데이터를 갖고 온다든지 하는 API적인 접근이 있을 때, 역할을 사용을 하게 되면 일정 시간 뒤에 Time Oute이 되는 임시 Credential를 가지고 권한을 수행할 수 있게 됩니다.

I is for Identity : 외부 사용자 -> IAM role

AWS 외부의 존재하고 있는 IAM User가 아닌 외부 보안주체에게 임시권한부여를 위해 IAM 역할을 사 용할 수 있다.

SAML 같은 연계프로토콜을 사용해서 외부 사용자를 역할과 매핑을 해주게 됩니다.

또한 다른 AWS 어카운트에 접근을 할 때도 역할을 사용해서 좀 더 안전한 접근을 구현할 수 있습니다.

 

AM is Access Management : AWS에서의 인가

 - 모든 AWS 서비스는 접근제어 정책을 기반으로 인가됨

 - 매 API 호출 시, 적용된 정책을 통해 인가 수행

 - 정책은 IAM 역할/사용자/그룹, AWS 리소스, 임시 자격증명 세션, OU 등에 적용할 수 있음

 - AWS Root 어카운트는 기본적으로 AWS 리소스에 대한 모든 권한을 가짐

 - AWS 정책은 기본 디폴트가 Deny이고, 명시적 Allow < 명시적 Deny의 우선순위

 

IAM Policy의 구조

{
  "Statement": [{
    "Effect": "Allow or Deny",  // 명시된 정책에 대한 허용 혹은 차단
    "Principal": "principal",  // 접근을 허용 혹은 차단하고자 하는 대상
    "Action": "action",  // 허용 혹은 차단하고자 하는 접근 타입
    "Resource": "arn",  / 요청의 목적지가 되는 서비스
    "Condition": {  // 명시된 조건, 유효하다고 판단될 수 있는 조건
     "condition": {
       "key": "value"
     }
    }
  }]
}

 

AM is Access Management: 요청의 성공 조건

제출된 요청이 성공하기 위해선

 1. IAM 보안 주체의 적법한 서명값이 포함되어 있고(인증)

 2. 정책(Policy)에 의해 해당 요청이 정확하게 인가되어야 함.

 

IAM 정책의 종류

정책	설명	포맷	정의 및 관리
identity-based 정책	IAM 보안 주체(IAM 사용자, IAM 그룹의 사용자 집합, IAM 역할)에 할당되어 해당 주체의 권한을 규정	JSON	IAM
Resource-based 정책	정책이 할당될 리소스를 기준으로 어떤 보안 주체가 할 수 있(없)는 작업을 규정.	JSON	개별 서비스들
IAM Permission Boundary 정책	IAM 보안 주체 별로 획득할 수 있는 권한의 최대치를 규정	JSON	IAM
Organization SCP	Organization의 OU 또는 개발 어카운트 별로 권한의 최대치를 규정 주로 Root 어카운트의 권한을 제한 시킬 때 사용.	JSON	Organization
Session 정책	임시 자격증명의 기존 퍼미션을 해당 세션에 대해서만 제한할 때 사용 AssumeRole, GerFerderation Token API의 파라메터로 전달됨.	JSON	STS
ACL 정책	리소스 기준으로 정의하며, 주로 Cross-Account 간의 리소스 공유시, 보안 주체에 대한 접근을 규정	XML	개별 서비스들
Endpoint 정책	VPC G/W Endpoint에 적용되는 접근제어 정책. 일종의 Resource-based 정책임	JSON	VPC

 

 

AWS IAM Best practice

IAM 모범 사례

 1. AWS 계정 Root 사용자 액세스 키 잠금

 2. 권한 있는 사용자에게 MFA 활성화

 3. 개별 IAM 사용자 만들기

 4. 그룹을 사용하여 IAM 사용자에게 권한을 할당

 5. 최소 권한 부여

 6. 서비스 권한 제어에 역할 사용

 7. 역할을 사용하여 권한 위임

 8. 자격 증명을 정기적으로 교체

 9. 보안 강화를 위해 정책 조건 사용

 10. AWS 계정의 활동 모니터링 및 감사

 

 루트 잠그기

 - AWS 계정 root 사용자 액세스 키 잠금

 - 권한있는 사용자에 대해 MFA 활성화

 

IAM 사용자 관리

 - 개별 IAM 사용자 만들기

 - 공통된 권한 그룹을 사용하여 IAM 사용자에게 권한을 할당

 

최소 권한 부여

 - Access Advisor : 최대 1년간의 기간 동안 저장된 데이터를 기준으로 마지막 접속 서비스에 대한 정보를 제공

 - Access Advisor 정보를 API를 통하여 조회 가능

 

AWS 계정의 활동 모니터링 및 감사

 1. AWS CloudTrail

 2. AWS IAM Access analyzer

 3. Amazon GuardDuty

 4. AWS Security Hub

 

 

AWS IAM Advanced

속성 기반 접근 제어

 - ABAC : Attribute Based Access Control

   : IAM 보안 주체의 요소(attribute, 태그)를 이용해서 단일 policy로 각기 다른 리소스에 재사용 가능한 접근 제어

 

클라우드 확장

	IAM Federation	AWS SSO	IAM Custom IdenfityBroker	Cognito User Pool	Cognito Identity Pool
저장소(Directory)	고객 / 소셜	고객 / AWS SSO	고객	Cognito User Pool	고객 / 소셜 / CUP
자격증명 공급자(IdP)	고객 / 소셜	AWS SSO	고객	Cognito User Pool	고객 / 소셜 / CUP
AWS 리소스 접근시, 자격 증명 교환	IAM	AWS SSO	고객	Cognito Identity Pool	Cognito Identity Pool
주요 용도	AWS 관리콘솔 연계	AWS 관리콘솔 연계	AWS 관리콘솔 연계	비즈니스 User 인증 / 인가	비즈니스 User 인증
지원 방식	SAML / OIDC	SAML	Custom	SAML / OIDC	SAML / OIDC / Custom

 

AWS Organizations

 - 멀티 AWS 계정 환경을 위한 AWS 계정의 중앙 거버넌스 및 관리 서비스

 - 조직 및 계정 관리 정의

 - 액세스 및 권한 제어

 - 규정 준수를 위한 환경 감사, 모니터링 및 보안

 - 여러 계정에서 리소스 공유

 - 비용 및 청구를 중앙에서 관리