[Dreamhack] AWS의 보안 설정(1)

AWS: Credentials

AWS 자격 증명

✅ AWS 사용자

• 루트 사용자 : AWS 서비스 및 AWS 계정에 관한 모든 권한을 가짐 → AWS 계정 폐쇄도 가능
• IAM 사용자 : AWS IAM으로 생성되는 계정으로, 루트 사용자 또는 IAM 권한을 가진 IAM 사용자가 생성 가능

 

✅ 접근 정책

1. 자격 증명 기반 정책 (Identity-based Policy)

: 주체가 할 수 있는 행동을 정의하는 것으로, 생성된 정책은 특정 주체와 연결되어 대상의 행동을 제어할 수 있음

 

▶ AWS Identity Access Management (IAM)에서 자격 증명 기반 정책 설정가능

[ 구성 요소 ]

• 사용자 : IAM 사용자
• 사용자 그룹 : 정책 관리자가 생성하는 사용자 계정의 집합 → 그룹에 정책 설정 시, 해당 그룹 구성원은 그 정책을 모두 상속하게 됨
• 역할 : 여러 대상에 부여할 수 있는 권한의 집합

 

2. 리소스 기반 정책

: 어떤 리소스를 대상으로 누가 무엇을 할 수 있는지 정의하는 정책

 

✅ Muti Factor Authentication

: 로그인 시, 아이디, 패스워드 외에 임의의 토큰을 입력하여 계정 보안을 강화하는 인증 체계로 3가지 방식의 MFA를 지원함.

MFA 방식	설명
Virtual MFA Device	시간을 기반으로 일회용 암호를 만드는 알고리즘 Time-based One-Time Password(TOTP)를 지원하는 모든 가상 장치를 지원한다. 예를 들어, 스마트폰에서 Google Authenticator 앱을 사용하는 방식이 있다.
Universal 2nd Factor (U2F)	USB 또는 NFC 장치를 사용해 인증하는 방식
Hardware MFA Device	물리적인 장치를 구매하고, 장치에 출력되는 6자리 숫자로 인증하는 방식

 

 

권장 사항

CR-01: 루트 사용자 API 키 비활성화

루트 사용자는 AWS 계정과 관련된 모든 권한을 갖고 있기 때문에 API 키를 분실하지 않는 것도 중요하지만, 애초에 사용하지 않는 것이 좋다.

▶ API 유출 사고 방지 가능

그림과 같이 액세스 키는 생성하지 않은 상태로 두는 것이 좋다.

 

CR-02: 다요소 인증 활성화

아이디, 패스워드 외에 임의의 토큰을 입력하여 계정 보안을 강화할 수 있다. 그 방법을 바로 다요소 인증(MFA)라고 하는데, AWS에서 'MFA 활성화를 통해 이를 설정할 수 있다.'

▶ 계정 보안 강화 가능

MFA 설정을 하면 위와 같이 멀티 팩터 인증에 표시되는 것을 볼 수 있다.

 

CR-03: 최소 권한의 원칙 적용

사용자에게 필요한 최소한의 권한만 부여하는 접근 통제 원칙

▶ 사용자의 권한 오남용을 막고, 계정 분실 시 발생할 수 있는 피해 제한 가능

 

[ 서로 다른 애플리케이션 개발 시, 권한 부여 방법 ]

1. IAM 정책을 관리할 사용자 생성
2. 팀마다 필요한 리소스에 대하서는 접근을 허용하지만, 나머지에 대해서는 모든 권한을 부인하는 정책 생성
3. 팀마다 적절한 정책이 연결된 사용자 그룹 생성
4. 사용자 그룹에 개발 인원 추가

 

CR-04: MFA 강제 정책 도입

MFA(다요소 인증)를 루트 사용자 뿐만 아니라 보안상 중요한 IAM 사용자에게 MFA 도입을 강제할 수 있음

▶ AWS 사용자에 대해 다요소 인증을 강제로 활성화하면, 계정 보안을 강화할 수 있음

→ MFA 강제 활성화 방법

 

 

AWS: Data Security

[ AWS 스토리지 ]

종류	설명	서비스
객체 스토리지	키로 식별되는 객체에 데이터를 저장하는 스토리지	S3, S3 Glacier
파일 스토리지	폴더 안에 데이터들이 단일 정보 형태로 저장되며, 경로를 통해 해당 데이터에 액세스 할 수 있다. 현대 운영체제의 폴더-파일 구조와 유사하다.	EFS, FSx
블록 스토리지	데이터를 여러 개의 블록으로 나누어 저장하는 스토리지로, 일반적으로 운영체제에 마운트해서 사용하는 스토리지가 이에 해당한다.	EBS

 

[ AWS 데이터베이스 ]

종류	설명	서비스
관계형 데이터베이스	완전 관리형 관계형 데이터베이스	RDS
키-값 데이터베이스	비관계형 키-값 데이터베이스	DynamoDB
문서 데이터베이스	비관계형 문서 데이터베이스, 몽고DB와 호환됨	DocumentDB

 

AWS S3

📂 AWS S3 (Simple Storage Service)
: AWS를 대표하는 '버킷-객체-데이터'의 구조를 갖는 객체 스토리지 서비스로, 사용자 저장 데이터 외에 AWS 서비스가 생성하는 로그들도 대부분 S3에 저장된다.

 

S3 버킷과 객체의 소유권

: S3 버킷과 객체의 소유권은 해당 리소스를 생성한 AWS 계정에 있다. 일반적으로 리소스 소유자만 접근할 수 있으며 다음은 리소스 소유권에 대한 몇가지 예시이다.

• AWS 계정으로 S3에 리소스를 업로드하면, 해당 계정이 소유권을 갖는다.
• 권한을 부여받은 IAM 사용자가 리소스를 업로드하면, 해당 사용자가 속한 계정이 리소스의 소유권을 갖는다.
• 버킷 소유자로부터 권한을 부여받은 다른 AWS 계정이 리소스를 업로드하면, 해당 계정이 소유권을 갖는다. 단, 버킷 소유자가 버킷 비용을 지불한다면, 소유권과는 별개로 리소스에 대한 모든 권한을 갖는다.
• 퍼블릭 버킷에 익명의 사용자가 리소스를 업로드하면, 해당 사용자에게 임시 ID를 부여하고 리소스의 소유권을 갖게 한다.

 

S3 리소스 접근 제어

S3에는 자격 기반 정책과 리소스 기반 정책이 모두 적용된다.

 

버킷 정책

버킷 정책은 버킷 및 버킷에 포함된 객체들에 대한 접근 권한을 정의하는 JSON 문서로, 아래는 임의 사용자의 접근을 허용하는 버킷 정책의 예시이다.

{
    "Version":"2021-05-01",
    "Statement": [
        {
            "Sid":"GrantAnonymousReadPermissions",
            "Effect":"Allow",
            "Principal": "*",
            "Action":["s3:GetObject"],
            "Resource":["arn:aws:s3:::awsexamplebucket1/*"]
        }
    ]
}

 

ACL

📂 ACL (Access Control List)
버킷 및 객체에 부착하여 접근 권한을 제한하는 JSON 문서

→ AWS는 ACL의 사용을 최소화하고, IAM 및 버킷 정책으로만 S3에 대한 접근을 제어할 것을 권장하고 있다.

 

사용자가 S3의 리소스에 접근하려고 하면 AWS는 IAM 정책, 버킷 정책, ACL을 모두 확인하여 자격을 검토한다. 이 세 가지 보안 계층에는 우선 순위가 없다. 셋 중 어느 한 요소에라도 명시적인 부인이 있으면, 접근을 거부한다. 그렇지 않고, 어느 한 요소에라도 명시적인 승인이 있으면 접근을 승인한다. 그 외의 경우에는 항상 접근을 거부한다.

 

 

S3 권장 사항

DS-S3-01: 퍼블릭 액세스 최소화

퍼블릭 액세스가 허용되면, 임의 사용자가 버킷에 데이터를 추가, 수정, 삭제할 위험이 있다. 데이터의 용도에 따라 여러 버킷을 생성하고, 퍼블릭 접근이 불필요한 버킷에는 이를 차단해주어야 한다. AWS는 버킷에 ‘모든 퍼블릭 액세스 차단’ 설정을 제공한다. 이는 버킷 정책이나 ACL보다 우선시 하므로, 이 설정을 활성화하면 ACL에서 퍼블릭 액세스를 허용해도, 퍼블릭 접근이 불가능하다.

 

▶ 악의적인 사용자가 버킷에 데이터 업로드 및 업로드된 데이터를 임의로 활용 불가능

위 이미지와 같이 해당 계정에서 퍼블릭 액세스를 허용할 버킷을 만들 것이 아니라면, 계정 자체의 S3 버킷 설정에서 퍼블릭 액세스 차단 설정을 하는 것도 좋은 방법이다.

 

DS-S3-02: 버킷 버전 관리 활성화

버킷의 상태를 버전으로 기록하는 기능으로, 활성화 시 S3는 객체를 모든 버전을 보존할 수 있다.

▶ 보안 사고로 데이터가 손실되었을 때, 복구 지점으로 사용 가능

 

DS-S3-03: 버킷 MFA 삭제 활성화

MFA 삭제는 AWS S3가 제공하는 기능으로, 버킷의 버전 관리 상태를 변경하거나, 객체의 특정 버전을 삭제하려고 하면 추가 인증을 요구하는 기능이다.

▶ 실수로 데이터를 삭제하는 사고 방지 및 계정 탈취 시, 데이터 손실 위험을 줄일 수 있음

→ AWS CLI, AWS SDK, Amazon S3 REST API로만 이를 활성화할 수 있다. 

 

DS-S3-04: 유휴 데이터의 암호화

서버 측 암호화, 클라이언트 측 암호화를 사용하여 S3의 데이터를 암호화할 수 있다.

• 서버 측 암호화 : AWS가 데이터를 암호화해서 서버에 저장 → 사용자가 이를 조회하면 AWS가 복호화해서 보여줌
• 클라이언트 측 암호화 : 사용자가 데이터를 암호화해서 S3에 저장하는 방식 → AWS가 이와 관련된 다양한 언어의 SDK 제공

▶ 데이터센터가 공격당해 데이터가 탈취되거나 서비스 제공자가 리소스를 제대로 격리하지 못해 탈취되는 사고를 예방할 수 있다.

 

DS-S3-05: CSP에 버킷 이름으로 와일드카드 사용 금지

📂 CSP (Content Security Policy)
Cross Site Script (XSS) 를 포함한 다양한 유형의 웹 공격으로부터 사용자를 보호하고, 관리자에게 침해 사실을 알리기 위해 도입된 웹 기술

 

웹 프론트에서 S3에 업로드된 자바스크립트를 사용하려면, 버킷 주소를 허용하도록 CSP 규칙을 작성해야 한다. 일반적으로, 버킷의 주소는 <bucket-name>.s3.<region>.amazonaws.com의 형태를 띈다.

간혹, 여러 개의 버킷을 활용할 경우, 개발자는 이들을 모두 허용하기 위해 *.s3.ap-northeast-2.amazonaws.com이라는 형태의 CSP 규칙을 작성할 수 있다. 이 경우, 공격자는 서울 리젼에 버킷을 생성하여 CSP 규칙을 우회할 수 있다.

따라서 여러 개의 버킷을 활용하더라도 와일드카드를 사용하지 말고, 각각의 버킷을 따로따로 허용해야 한다.

▶ 버킷 생성으로 CSP를 우회하는 공격 차단 가능

 

DS-S3-06: CloudTrail로 객체 수준 API의 사용 로그 기록

CloudTrail을 활용하여 객체를 대상으로 사용된 API들의 정보를 기록할 수 있다.

▶ 보안 사고 발생 시, 원인을 파악하고 적절히 대응할 수 있도록 정보 제공 가능