7. 세큐리티와 아이덴티티

AWS 아카운트의 종류

AWS 에는 AWS 아카운트와 IAM 유저 라고 불리는 2가지 종류의 아카운트가 있다.

AWS 아카운트는 AWS에 사인업할 당시에 작성된 아카운트이다. 이 아카운트는 AWS의 모든 서비스를 네트워크 상 어디서든 이용 가능하기 때문에, 이 아카운트를 루트 유저(Root User) 라고 부른다.

반면, IAM 유저의 경우 AWS를 이용하는 각 이용자를 위해 작성된 아카운트이다. 처음 AWS 아카운트를 작성했을 경우 IAM 유저는 존재하지 않는다. AWS 아카운트로 로그인한 뒤 필요에 응하여 IAM 유저를 작성할 수 있다.

또한 복수의 AWS 아카운트를 관리하기 위해 AWS Organizations (기업 아카운트) 라고 하는 기능도 준비되어 있다. 조직 아카운트를 이용하는 것으로 복수의 아카운트에서 발생하는 청구를 하나로 모아 일괄적으로 관리할 수 있다.

또한 이용 가능한 서비스를 AWS 아카운트 단위로 제한하는 서비스 컨트롤 폴리시 (SCP) 를 이용 할 수 있다.

AWS 아카운트

AWS 아카운트의 유저는 루트 유저라고 불리며, AWS의 전 서비스에 대하여 네트워크 상의 어디서든 조작 가능한 권한을 가지고 있다. 매우 강력한 권한을 가진 아카운트이기 때문에 취급에 주의할 필요가 있다. AWS에서 시스템을 구축, 운용 하는 경우 AWS 아카운트를 이용하는 것은 되도록 피하도록 하며, IAM 유저를 이용하는 것을 추천한다. 또한 AWS 아카운트 자체로는 루트 유저에 IP 주소 제한을 거는 등, 이용에 제한을 하는 방법이 없다. 그렇기 때문에 다요소인증 (Multi-Factor Authentication, MFA)의 설정을 해두는 것을 매우 권장한다.

IAM 유저

AWS의 각 이용자가 web 콘솔에 로그인하여 조작하거나, API를 이용하여 조작하는 등에 사용된다. 각 IAM 유저에 대하여 조작을 허가하는 리소스 서비스를 정의할 수 있다. IAM 유저의 권한을 올바르게 제한하는 것으로 AWS를 보다 안전하게 사용할 수 있다.

예를 들어 EC2 인스턴스의 start/stop 에 관한 권한만 부여하고 Terminate는 할 수 없는 IAM 유저를 작성하거나, 네트워크 (세큐리티 그룹이나, VPC, Route53 등)에 관련된 권한만 가진 네트워크 관리자용 IAM 유저를 작성하는 것도 가능하다.

IAM 유저의 관리는 세큐리티 측면에서의 메인이 될 수 있다. VPC나 EC2, S3를 어떻게든 세큐어하게 관리하고 있다 해도, IAM 유저의 관리가 허술 하다면, 간단히 AWS 자체를 해킹 당할 수 있다. IAM 유저는 그 정도로 중요한 포인트이다. IAM 유저 이외에도 다양한 기능이 있다.

IAM (Identy and Access Management) 의 기능

• IAM 폴리시
• IAM 유저
• IAM 그룹
• IAM 롤

이러한 기능을 활용하여 유저에게 권한을 부여하는 흐름은 다음과 같다.

1. AWS 서비스나 AWS 리소스에 대하여 조작 권한을 IAM 폴리시 로서 정의한다.
2. IAM 폴리시를 IAM 유저나 IAM 그룹에 할당한다.
3. IAM 유저 또는 IAM 그룹에 속하는 IAM 유저가 매니지먼트 콘솔에 로그인하여 부여된 권한의 조작을 행하는 것이 가능하다.

이 흐름을 머리에 정리해두고, 기능의 설명을 하나씩 읽다 보면 이해하기 편할 것이다. 또한 IAM 유저는 이용자를 특정하는 것 (Identity) 을 전제로 이용한다. 이것에 대하여 IAM 롤은 필요에 응하여 어느정도 권한을 부여할 것인가와 같은 역할을 부여하는 서비스이다. 모두 중요한 역할을 하고 있는 서비스이므로, 제대로 이해해둘 필요가 있다.

IAM 폴리시

Action( 어떤 서비스의 ), Resource ( 어떤 기능이나 범위를 ), Effect (허가, 거절) 이라고 하는 3가지 커다란 룰에 근거하여 AWS 의 각 리소스 서비스를 이용하는데 있어, 다양한 권한을 설정할 수 있다. 이런 식으로 작성된 폴리시를 IAM 유저, IAM 그룹, IAM 롤 에 의해 권한을 제어한다.

인라인 폴리시와 관리 (매니지드) 폴리시

IAM 에는 유저나 그룹, 롤에 부여하는 권한을 오브젝트로서 관리하는 것이 가능하며, 이것을 폴리시라고 부른다. 폴리시에는 인라인 폴리시, 관리 (매니지드) 폴리시가 있다.

인라인 폴리시에는 대상별로 작성, 부여하는 폴리시로 복수의 유저, 그룹에 같은 권한을 부여하는데는 알맞지 않는다.

이에비해 관리 폴리시는 하나의 폴리시를 복수의 유저나 그룹에 적용할 수 있다. 관리 폴리시에는 AWS  관리 폴리시와 커스터머 관리 폴리시 2종류가 있다. AWS 관리 폴리시는 AWS측이 준비해둔 폴리시로 관리자 권한이나 PowerUser, 또는 서비스 별의 폴리시등이 있다. 

반면 커스터머 폴리시는 유저 자신이 관리하는 폴리시이다. 작성 방법 자체는 인라인 폴리시와 동일하지만, 개별의 유저, 그룹내에 닫힌 정책인지 공유할 수 있는지에 차이가 있다. 또한 커스터머 관리 폴리시는 최대 과거 5대까지의 버전을 관리할 수 있다. 변경한 권한에 문제가 있을 경우, 이전 버전의 권한으로 되돌리는 것도 가능하다.

사용 방법에 대해선 AWS  관리 폴리시로 기본적인 권한을 부여하고, 커스터머 폴리시로 IP 주소 등을 제약하는 식으로 접근할 수 있다. 인라인 폴리시에 대해서는 관가 복잡해지기 때문에, 기본적으로는 사용하지 않는 방침이 좋다. 하지만 일시적으로 개별 유저에 권한을 부여할 경우에는 사용하는 쪽으로 고려할 수 있다.

인라인 폴리시와 관리 폴리시의 차이

IAM 유저와 IAM 그룹

유저란 AWS를 이용하기 위해 각 이용자에 하나씩 부여진 인증 정보 ( ID )이다. 지금 까지 설명한 IAM 유저와 같다고 생각할 수도 있다. 여기서는 이용자로서 사람뿐만 아니라 API를 호출하거나, CLI를 이용하거나 하는 주체도 포함된다. IAM 유저의 인증 방법에는 아래 2가지 방법이 있다.

• 유저 ID와 패스워드 : web 콘솔에 로그인할 때에 사용한다. 다용도인증 (MFA) 를 조합하여 사용하는걸 권장한다.
• 액세스키와 시크릿 액세스키 : CLI나 API 로 부터 AWS의 리소스에 액세스할 경우 사용한다.

또한 그룹은 같은 역할을 가진 유저의 집합이다. 그룹은 AWS로의 액세스 인증 정보를 보유하지 않는다. 인증은 어디까지나 유저가 행하며, 그룹은 인증된 유저가 어떤 권한 (서비스의 이용 가능/불가능) 을 가진지를 관리한다. 그룹의 목적은 권한을 쉽고 정확하게 관리하는 것이다. 복수의 유저에 동일한 권한을 개별로 부여하면 잘못된 권한의 부여 문제가 발생할 확율이 높아진다.

유저와 그룹은 다대다 관계를 가지는 것이 가능하기 때문에, 하나의 그룹에 복수의 유저가 속하는 것도 가능하며,  한명의 유저가 복수의 그룹에 속하는 것도 가능하다. 하지만 그룹을 계층화 하는것은 불가능하기 때문에, 그룹에 일정한 권한을 정리해두고, 사용자에게 필요한 그룹을 할당하는 식으로 관리할 수 있다.

IAM 그룹의 구성 예

IAM 롤

IAM 롤 은 영속적인 권한 (액세스 키, 시크릿 액세스 키) 를 가진 유저와는 다르게 일시적인 AWS 리소스로의 액세스 권한을 부여할 경우에 사용한다. 예를 들어 아래와 같은 사용방법을 이용할 경우에는 롤을 정의하여 필요한 AWS 리소스에 대하여 액세스 권한을 일시적으로 부여하는 것으로 실현할 수 있다. 롤의 생각 방법은 조금 복잡하지만, 잘 사용할 수 있게 된다면 굉장히 편리하다.

• AWS 리소스로의 권한 부여 : EC2 인스턴스 상에서 기동하는 애플리케이션에 일시적으로 AWS 리소스에 액세스 하는 권한을 부여하고 싶을 경우(EC2 인스턴스 작성시에 롤을 부여하는 것도 가능) 
• 크로스 아카운트 액세스 : 복수의 AWS 아카운트 간의 리소스를 하나의 IAM 유저로 조작하고 싶을 경우
• ID 연합 : 사내의 AD (Active Directory) 서버에 등록된 아카운트를 사용하여 AWS 리소스에 액세스하고 싶을 때
• Web ID 연합 : Facebook이나 Google의 아카운트를 사용하여 AWS 리소스에 액세스하고 싶을 때

여기에선 가장 많이 사용하는 EC2 인스턴스에 롤을 부여하여 인스턴스 내에 애플리케이션으로 부터 AWS리소스에 액세스하는 방법을 설명하려고 한다. 구체적인 사용 예로는 EC2 인스턴스 상에서 기동하는 애플리케이션으로 부터 SES를 사용하여 메일을 송신하는 경우를 상정한다.

1. 우선 최초의 IAM롤을 작성한다. 롤 작성시에는 EC2 인스턴스만 해당 롤을 취득 할 수 있도록 롤 타입 (Amazon EC2 )를 선택한다. 그리고 롤에 대하여 필요한 권한 (AmazonSESFullAccess)를 부여한다.
2. 다음 작성한 롤을 EC2 인스턴스에 부여한다. EC2 인스턴스에 롤을 부여할 수 있는 것은 처음의 인스턴스 작성시 뿐이다. 기존의 인스턴스에 추가적으로 롤을 부여하는것은 불가능하다. 기존의 인스턴스에 롤을 부여하고 싶을 경우에는 한번 AMI를 작성하고 AMI로 부터 새롭게 EC2 인스턴스를 작성하면 되는데, 이때 롤을 설정하고 싶은 것을 선택하도록 하자.
3. 2번에서 작성한 EC2 인스턴스 상에서 SES를 사용하여 메일을 송신하는 프로그램을 기동 시킨다. 이러한 프로그램에는 보통 SimpleEmailService 클래스의 오브젝트 생성시에 액세스키와 시크릿 액세스키를 인증 정보의 인수로서 전하지만, 이번 프로그램에는 인스턴스의 부여된 롤으로 부터 인증 정보를 일시적으로 취득하기 때문에, 이런 키는 불필요하다.
4. SES로의 액세스 정보를 롤 로 부터 일시적으로 취득한 애플리케이션은 메일을 송신이 가능하게 된다.

이렇 듯 인스턴스에 롤을 부여하는 것으로 프래그램이나 설정 파일에 인증 정보 (액세스키, 시크릿 액세스키)를 기록할 필요가 없으며, 세큐리티를 향상 시킬 수 있다.

IAM 롤의 이용 이미지

KMS와 CloudHSM

기밀성이 높은 데이터를 운용하기 위해선 암호화 구축이 필요하다. 그런 경우 중요한 것은 암호화나 복호화를 위한 키를 관리하는 것이다. AWS Key Management Service (KMS) 나 AWS CloudHSM (CloudHSM) 은 암호화 키의 작성과 관리를 위한 서비스이다. 아키텍처를 검토하는데 있어, 시험 대책으로도 중요한 서비스이다. 보다 상위의 프로페셔널한 레벨의 시험을 치를 경우에는 빈번히 출제되기도 한다. 그럴 정도로 이 부분은 중요하다고 할 수 있다.

KMS와 CloudHSM

AWS에는 키 관리의 서비스로서, KMS 와 CloudHSM이 있다. CloudHSM은 VPC내에 전용 하드웨어를 이용하여 키를 관리하는 서비스이다. 이것에 대하여 KMS는 AWS가 관리하는 매니지드 서비스이다. 양쪽의 커다란 차이는 신뢰의 거점 (Root of Trust)이 유저 자신인지, AWS 측인지의 차이이다.

구분	CloudHSM	KMS
특징	VPC내의 전용 하드웨어 디바이스	AWS 가 관리하는 멀티 테넌트
가용성	유저측 관리	AWS측이 고가용성, 내구성 설계
신뢰의 거점	유저측 관리	AWS측 관리
암호화 기능	공유키 또는 공개키	공통키
코스트	거의 고정비용	종량과금

CloudHSM은 전용 하드웨어를 이용하고 있기 때문에, 초기 코스트와 월별 고정비용이 필요하다. 그렇기 때문에, 어지간히 큰 규모의 시스템이나 특정 규제, 법령에 준거하는 목적이 있는게 아니라면, 이를 이용하는 경우가 흔치는 않을 것이다. 실제로 사용하는 케이스도 KMS의 경우가 압도적으로 많을 것이라 생각한다.

 

시험의 대책적인 측면에선 양쪽의 차이와, 사용법을 이해하는 것으로 충분한하다. 아키텍처 설계의 포인트로는 초당 100을 넘는 암호화 리퀘스트가 있다, 또는 공개키 암호화를 사용하고 싶을경우에는 CloudHSM을 이용하며, 그 이외에는 KMS를 사용하는 방식이 될 것이다.

KMS의 기능

KMS의 주요 기능은 키 관리 기능과, 데이터 암호화 기능이다. 이중에 데이터 암호화 기능으로서 아래 3가지의 API가 있다.

• Encrypt
• Decrypt
• Generate Data Key

Encrypt는 문자 그대로 데이터를 암호화 하기 위한 API 이다. 4KB 까지의 평문 데이터를 대응하고 있으다. 

Decrypt는 복호를 위한 API이다. 

GenerateDataKey는 유저가 데이터의 암호화에 이용하기 위한, 커스터머 데이터키를 생성한다. 평문의 키와 Encrypt API로 암호화 된 키를 반환한다. 이것을 이해하는 것은 마스터키와 데이터키의 개념을 이해할 필요가 있다.

마스터키와 데이터키

KMS에는 주로 2가지의 키를 관리한다. 마스터 키와 데이터 키로 AWS에는 Customer Master Key (CMK) 또는 Customer Data Key (CDK)로 표기되는 경우가 많다.  CMK는 데이터키를 암호화 하기 위한 키이다. CDK는 데이터를 암호화 하기 위한 키이다. KMS에는 데이터의 암호화에 관하여 데이터키로 데이터를 암호화 한 뒤 해당 데이터 키를 마스터키로 암호화 하는 방법을 취하고 있다. 이것은 데이터키의 보호를 위함이며, 이 방법을 엔벨로프 암호화 라고 불린다.

키의 계층구조

이렇듯 2계층 구조로 되어 있는 것은 세큐리티 향상을 위함이다. 우선 데이터키에 대해서는 기본적으로 S3, EBS, Redshift등 암호화의 대상 별로 작성한다. 그렇게 하는 것으로 인해 데이터키에 누설이 발생했을 경우 리스크를 한정화 시킬 수 있다. 데이터키를 마스터키로 암호화 하는 것으로 실제의 운용에 사용할 기회가 많은 데이터키를 보호한다. 그리고 마스터 키를 집중 관리하는 것으로 인해 전체의 세큐리티를 향상시킬 수 있다.

클라이언트 사이드 암호화와 서버 사이드 암호화

암호화에 대해서는 어디서 암호화 하는 가 하는 점도 중요하다. 클라이언트 측에서 할 것인지, 서버 측에서 할 것인지에 대한 것이다.

클라이언트 사이드 암호화는 유저측의 처리로 암호화를 하는 방식이다. 많은 경우 AWS 가 제공하는 SDK를 이용하여 행한다. EC2나 Lambda 내의 프로그램에서 암호화 하여 S3 에 업로드 할 경우에도 클라이언트 사이드 암호화가 이뤄진다. UseCase또한 경로의 안전성이 보장되지 않을 경우는 클라이언트 측에서 암호화 하여 데이터를 보낸다.

이에 대하여  AWS 측의 처리로 암호화 할 것이 서버 사이드 암호화 이다. AWS의 서비스가 암호화 대응일 경우에는 기본적으로 서버 사이드 암호화가 이용되고 있는 것이다. 클라이언트 사이드 암호화 서비스는 적으며, 해당하는 것은 S3등의 일부 서비스 뿐이다.

AWS Certificate Manager

모든 정보가 인터넷을 통해 교환되고 있는 현재, 통신의 암호화는 필수 요소이다. 서버와의 주고 받는 암호화 및 해당 서버의 신뢰성을 확인하기 위해, 서버 증명서가 이용된다. 이때 이용되는 프로토콜이 SSL(Secure Sockets Layer), TSL (Transport Layer Security)로 SSH 증명서 라 불리는 경우가 많다. 덧붙여 SSL 증명서라고 불리고 있지만 SSL3.0을 기초로 한 후계 프로토콜 TLS 1.0이 제정된 이후 실제로 사용되고 있는 것은 TLS이다. SSL3.0 은 취약성이 있기 때문에 이미 권장할 수 없게 되었다.

인증서의 역할과 신뢰

인증서를 이용하여 실현 가능한 것은 주로 2가지가 있다. 하나는 경로간의 통신의 안전성의 확보이다. 이것에는 통신 내용을 도청 당하지 않게 하기 위한 암호화로 통신 내용의 조작을 방지하고 있는 것이다.

또 하나는 통신하고 있는 상대가 누구인지의 증명이다. 본인임을 증명하기 위해선 신뢰성이 높은 제3자가 필요하다. 이를 위해 SSL 증명서는 인증국 (Certification Authory, CA) 라고 하는 증명서를 관리하는 기관에 의해 발행된다.

증명 방법에는 아래 4가지 방법이 있다. 또한 증명의 종류와 암호화의 강도의 사이에는 상관관계는 없다.DV보다 EV가 강한 암호가 사용된다. 와같은 경우는 없다.

• 자기 인증서 : 자신이 인증국을 세워 인증서를 발급 ( 제3자에 의한 인증이 없다 )
• 도메인 인증(DV) : 도메인의 소유만을 인증, 조직 정보의 확인은 하지 않는다.
• 조직 인증(OV) : 조직 정보의 심사를 거쳐 인증한다.
• 확장 인증(EV) : OV 보다 엄격한 심사로 인증한다.

ACM

AWS Certificate Manager의 약자로 AWS자신이 인증국으로서 DV 증명서를 발행하는 서비스이다. ACM은 2048비트 모듈 RSA 키와 SHA-256의 SSL/TLS 서버 증명서의 작성, 관리를 행하는 서비스이다. ACM의 증명서의 유효기간은 13개월이며, 자동 갱신하도록 설정하는 것이 가능하다. ACM을 이용할 수 있는 것은 AWS의 서비스 뿐이지만, ACM에는 [무료] 라고 하는 매우 강한 어드벤테이지가 존재한다. ACM의 초기 설정시에는 도메인의 소유의 확인이 필요하다. 도메인의 소유의 증명에는 메일 송신 또는 DNS를 이용한다.

연동 가능한 서비스

ACM은 AWS의 서비스만 이용 가능하다. 2020년 12월을 기준으로 이용 가능한 서비스는 아래와 같다.

 

• Elastic Load Balancing (ELB)
• Amazon CloudFront
• AWS Elastic Beanstalk
• Amazon API Gateway
• AWS Nitro Enclaves

또한 Elastic Beanstalk는 서비스내에 이용하는 ELB에 대하여 설정 가능하다. 또한 ELB중 ACM을 이용 가능한 것은 ALB (Application Load Balancer) 뿐이다.