1. 개요
일반적으로 AWS로 프로젝트를 진행하다 보면, Amazon Aurora를 많이 사용하게 됩니다.
Aurora에 저장되는 데이터가 민감 정보이거나 개인 정보로 식별이 된다면 반드시 DB 접근제어 솔루션을 통해 보안을 강화하여야 합니다.
하지만 작은 프로젝트의 경우 소수의 개발자/엔지니어 통제를 위해 상용 DB 접근제어를 도입하기엔 비용에 부담이 될 수 있습니다.
이번 포스팅에서는 AWS 기능을 이용한 DB 접근제어 방안을 살펴보겠습니다.
*참고* DB 접근 제어의 요건
• 누가 데이터에 액세스하거나 수정했습니까?
• 데이터에 액세스하거나 수정 한시기는 언제입니까?
• 특정 사용자가 데이터에 액세스하는 방법은 무엇입니까?
• 변경이 이루어지기 전에 데이터베이스 테이블에 대한 변경이 승인되었습니까?
• 권한 있는 사용자가 수퍼 유저 권한을 남용하고 있습니까?
2. DB 접근 제어 방안
2.1 아키텍처 다이어그램
2.2 아키텍처 설명
- 개발자 및 엔지니어는 System Manager Session Manager(이하 SSM)을 통해 Bastion Host에 접근합니다.
a. Bastion Host 보안
i. Bastion Host에 SSM으로 붙을 수 있는 IAM User는 Policy로 통제합니다.
ii. Bastion Host 접속 후 리눅스 계정인 ssm-user에서 su(switch user)를 통해 개인의 계정으로 변경합니다.
1. Cloud Trail을 통해 IAM User의 SSM 접근 로그를 저장합니다.
2. su로 유저 전환 시 Password를 요구하며, Password 정책은 Pam.d 설정을 통해 강화합니다.
3. SSM을 통해 접근 시, SSM Log를 통해 사용자가 붙은 세션 로그(명령어 등)를 S3에 저장합니다.
- Bastion Host에서 Aurora DB에 생성된 개인 DB 계정으로 로그인합니다.
a. IAM 데이터베이스 인증 토큰은 AWS 액세스 키를 사용하여 생성됩니다. 데이터베이스 사용자 자격 증명을 저장할 필요가 없습니다.
b. 인증 토큰의 수명은 15분이므로 암호를 재설정하도록 강제할 필요가 없습니다.
c. IAM 데이터베이스 인증에는 보안 소켓 계층(SSL) 연결이 필요합니다. DB 인스턴스와 주고받는 모든 데이터는 암호화됩니다.
d. 애플리케이션이 Amazon Elastic Compute Cloud(Amazon EC2)에서 실행되는 경우 EC2 인스턴스 프로파일 보안 인증 정보를 사용하여 데이터베이스에 액세스할 수 있습니다. 인스턴스에 데이터베이스 암호를 저장할 필요가 없습니다.
- Aurora DB Instance의 Audit Log Enable 설정으로 Audit Log는 CloudWatch Log Group으로 전달됩니다.
- CloudWatch Logs를 통해 DB에 접근한 시간, 사용자, 명령어, SQL 문 등이 저장됩니다.
3. 아키텍처 검증 데모
DB 접근 제어에 대한 검증 데모로 Bastion Host 접근에 대한 내용은 생략합니다.
3.1 데모 내용
- IAM User를 사용한 DB 접근
- Aurora DB Audit Log 활성화 및 로깅 설정
- DB 접근 감사 검증
3.1.1 IAM User를 사용한 DB 접근
1. RDS DB 인스턴스의 데이터베이스 인증 옵션을 ‘암호 및 IAM 데이터베이스 인증’으로 변경합니다.
: [RDS] > [데이터베이스] > 대상 클러스터 or DB > 수정
2. AWS 인증 토큰을 사용하는 데이터베이스 사용자 계정을 생성합니다.
a. mysql 설치
b. 유저 생성 권한이 있는 DB User로 사용자 계정 생성
i. SQL 문
ii. 예시
3. 데이터베이스 사용자를 매핑하는 IAM 정책 추가
: DB에 연결하고자 하는 IAM User에 다음과 같은 Policy를 생성하여 연결합니다.
a. 예시
(참고 URL : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html)
4. AWS 인증 토큰을 생성하여 IAM 역할 식별
a. 명령어
b. 실행화면
5. IAM 역할 자격 증명과 인증 토큰을 사용하여 RDS DB 인스턴스에 연결
a. 명령어
b. 실행화면
3.1.2 Aurora DB Audit Log 활성화 및 로깅 설정
1. (Aurora Mysql 8.x 기준) DB 파라미터 그룹 변경
a. server_audit_logging : 1
b. server_audit_events : CONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML, TABLE
c. (참고) 감사 구성 옵션 – CONNECT – Connection 성공, Connection 실패, 그리고 disconnections에 대한 로그. 이 값에는 사용자 정보가 포함됩니다.
- QUERY – 구문 또는 권한 오류로 인해 실패한 쿼리를 포함하여 모든 쿼리 텍스트 및 쿼리 결과를 일반 텍스트로 기록합니다.
- QUERY_DCL – QUERY와 유사하지만 DCL 타입 쿼리 (GRANT, REVOKE 등)만 반환합니다.
- QUERY_DDL – Query와 유사하지만 DDL 타입 쿼리 (CREATE, ALTER 등)만 반환합니다.
- QUERY_DML – Query와 유사하지만 DML 타입 쿼리 (INSERT, UPDATE 등)만 반환합니다.
- TABLE – 쿼리 실행의 영향을받은 테이블을 기록합니다. 이 옵션은 Amazon Aurora MySQL에 대한 고급 감사에서만 지원됩니다.
(관련 URL : https://aws.amazon.com/ko/blogs/korea/configuring-an-audit-log-to-capture-database-activities-for-amazon-rds-for-mysql-and-amazon-aurora-with-mysql-compatibility/)
2. CloudWatch 로깅 설정
: [RDS] > [데이터베이스] > 대상 클러스터 or DB 인스턴스 > 수정
3.1.3 DB 접근 감사 검증
- DB 명령어 사용
- CloudWatch 로그 확인
a. CloudWatch 로그 그룹
b. 로그 스트림 확인
c. 로그 이벤트를 필터링으로 검색
: db 유저명(dongin)으로 필터링
4. 마무리
이번 포스트를 통해 AWS 서비스만을 이용하여 DB 접근 제어의 필요 기능을 구현할 수 있었습니다.
위의 데모 설정 외에도 특정 유저, 특정 쿼리문, 특정 테이블로 제한하여 감사하거나, 감사된 메시지를 필터 하여 알람을 설정할 수도 있습니다.
프로젝트에서 위와 같은 설정을 통해 DB 접근 사용자를 통제하고 중요한 데이터베이스를 감사할 수 있도록 설정하여 보다 강력한 보안 아키텍처를 구축할 수 있습니다.