Amazon RDS에서 민감한 데이터 보안을 위한 모범 사례

AWS 고객이 클라우드 데이터베이스에 저장한 데이터 보안 및 제어는 매우 중요합니다. 이 글에서는 Amazon RDS 데이터베이스에 보안 개념의 구현 작업을 살펴봅시다.

1. 데이터 분류 및 보안 영역 모델링

데이터 분류 및 보안 영역 모델링에 대한 Amazon RDS 적용 방법을 살펴 보겠습니다. (더 자세한 설명을 원하거나 데이터 분류 및 보안 영역 모델링의 개념에 대해 알고 싶은 경우에는 본 시리즈의 첫 번째 게시물을 참조하십시오.)

데이터 분류

이 게시물의 뒷부분에서 설명하는 보안 제어 중 어떤 것을 사용자에게 적용할지 결정하려면 데이터 분류를 이해해야 합니다. 예를 들어, 데이터의 토큰화 또는 보안 마이크로세그먼테이션과 같은 특정 보안 제어가 필요하지 않을 수 있습니다. 두 개념은 이 게시물의 뒷부분에서 설명합니다. 이러한 보안 제어가 필요하지 않은 경우는 데이터베이스에 신용카드 번호 또는 사회 보장 번호와 같은 매우 중요한 데이터가 없는 경우가 해당됩니다.

보안 영역 모델링

보안 영역을 디자인한 후에는 네트워크 액세스 제어 목록(ACL)을 사용하여 구현하십시오. 전체 서브넷을 네트워크 플로우 제어 장벽으로 사용할 것을 권장합니다. 이 게시물의 뒷부분에 있는 보안 그룹 및 네트워크 ACL 섹션에서 네트워크 ACL을 사용하여 보안 영역을 구현하는 방법을 소개합니다.

보안 영역 모델링을 구현할 때는 네트워킹 디자인을 신중하게 고려해야 합니다. CIDR 범위의 크기에 따라 각 서브넷이 유지할 수 있는 IP 주소의 수가 결정됩니다. 서브넷 내부에서의 증가(IP 주소 증가)와 서브넷 수의 증가를 지원할 수 있도록 CIDR 범위를 설계합니다. Amazon VPC와 온프레미스 데이터 센터 간 또는 VPC 간에 호환 가능한 IP 주소 공간을 확보하기 위한 모든 요구 사항과 균형을 유지해야 합니다. 자세한 내용은 AWS Answers 사이트의 AWS Single VPC Design을 참조하십시오.

2. 심층 방어

RDS에서 심층적인 방어를 위한 보안 제어 작업에 대해 자세히 알아보기 전에 이 게시물의 뒷부분에서 설명하는 보안 구성을 다루는 RDS 시작 마법사 섹션을 살펴봅시다.

기본 보안 설정

네트워크 및 암호화 등 기본 보안 구성 설정으로 이동하려면 AWS 관리 콘솔에서 RDS로 이동하십시오.

Create Database를 선택합니다. 이 블로그 게시물의 목적 달성을 위해 Aurora MySQL 데이터베이스 인스턴스를 이용합니다.

게시물의 뒷부분에서 설명하는 RDS 보안 제어의 일부로 수정할 내용을 살펴봅시다. 3단계 – 고급 설정 구성이 나타날 때까지 시작 마법사를 따르십시오.

이 블로그 게시물에서 다루는 보안 제어와 관련이 없는 다른 기본 RDS 구성을 수정하는 것은 이 게시물이 다루는 범위를 벗어납니다. Aurora 데이터베이스 인스턴스를 시작하기 위한 단계별 안내서의 전체 내용을 따르려면 RDS 설명서에서 Amazon Aurora 시작하기를 참조하십시오. 기타 RDS 데이터베이스 엔진에 대해서는 Amazon RDS 시작하기를 참조하십시오.

이제 방어를 심층적으로 강화하는 보안 제어에 대해 논의해 봅시다. 제어에는 예방 제어와 감시 제어라는 두 가지 주요 범주가 있습니다.

예방 제어

DDOS 보호

AWS Shield Standard 및 Advanced를 사용하여 분산 서비스 거부(DDoS) 공격으로부터 애플리케이션 및 데이터베이스를 보호할 수 있습니다. 모든 AWS 고객은 추가 비용 없이 AWS Shield Standard의 자동 보호가 주는 이점을 누릴 수 있습니다. AWS Shield Standard는 웹 사이트나 애플리케이션을 대상으로 하며 가장 일반적이며 자주 발생하는 네트워크 및 전송 계층을 방어합니다. Amazon CloudFront 및 Amazon Route 53에서 AWS Shield Standard를 사용하면 잘 알려진 모든 인프라(계층 3 및 4) 공격에 대해 포괄적인 가용성 보호를 받을 수 있습니다.

DDOS 대응팀에 24시간 연중 무휴로 액세스하는 등 더 높은 수준의 보호를 받기 위해 AWS Shield Advanced에 가입할 수 있습니다. 사용 가능한 추가 보호 기능에 대한 자세한 내용은 AWS Shield Advanced 기능 페이지를 참조하십시오. 다음은 AWS Shield Advanced를 활성화하는 예시입니다.

AWS 콘솔에서 AWS WAF 및 AWS Shield로 이동합니다. 아직 AWS WAF 또는 AWS Shield Advanced를 활성화하지 않은 경우에는 다음과 같은 페이지가 나타납니다. 그렇지 않으면 AWS WAF 및 AWS Shield 대시보드 페이지가 나타납니다.

Standard와 Advanced를 비교한 내용을 확인하려면 AWS Shield를 선택하십시오. 이 예제에서는 AWS Shield Advanced를 사용하도록 설정합니다.

애플리케이션 레벨 위협 예방

애플리케이션 레벨의 위협 방지를 위해 다음과 같이 AWS WAF 및 데이터베이스 방화벽을 사용할 것을 권장합니다.

AWS WAF

웹 애플리케이션은 데이터베이스에 저장된 데이터에 액세스해야 합니다. 따라서 SQL 인젝션 및 개방형 웹 애플리케이션 보안 프로젝트(OWASP)의 웹 애플리케이션에서 가장 중요한 보안 위험 중 상위 10가지 등과 같은 애플리케이션에 대한 공격을 사용하여 데이터를 누출로부터 보호하는 것이 중요합니다. (자세한 내용은 OWASP 사이트를 참조하십시오.) AWS WAF를 구성하여 이를 Amazon CloudFront 배포 또는 Application Load Balancers에서 활성화하여 애플리케이션을 이러한 위협으로부터 보호할 수 있습니다.

AWS WAF로 작업을 시작하려면 콘솔에서 AWS WAF 및 AWS Shield로 이동하십시오. 아직 AWS WAF 또는 AWS Shield Advanced를 활성화하지 않은 경우에는 다음과 같은 페이지가 나타납니다. 그렇지 않으면 AWS WAF 및 AWS Shield 대시보드 페이지가 나타납니다.

계정의 첫 번째 웹 ACL 인 경우 다음 과 같은 페이지가 나타납니다.

그렇지 않으면 다음과 같이 새 웹 ACL을 만듭니다.

그런 다음, 웹 ACL을 구성합니다.

AWS WAF 규칙을 설정하려면 먼저 애플리케이션 레벨 위협 탐지에 사용할 조건을 일부 만듭니다. 다음은 SQL 인젝션 조건을 생성하는 예제입니다. 각각 여러 필터를 사용하여 여러 조건을 만들 수 있습니다.

그런 다음, 위의 조건을 사용하는 AWS WAF 규칙을 만듭니다.

데이터베이스 방화벽

애플리케이션 레벨 공격으로부터 보호하기 위한 또 다른 접근법은 AWS 파트너로부터 데이터베이스 방화벽 솔루션을 구현하는 것입니다. 이러한 솔루션은 AWS Marketplace에서 찾을 수 있습니다.

네트워크 격리

민감한 데이터를 위한 주요 보안 고려 사항은 데이터베이스의 네트워크 격리입니다. 네트워크 격리는 데이터베이스가 프라이빗 IP 주소 범위에서만 데이터베이스에 액세스해야 하는 구성 요소에만 액세스하도록 합니다. 이 보안 격리를 활성화하는 기본 설계 구성 요소는 Amazon VPC입니다. 데이터베이스 인스턴스를 만들 때 VPC를 데이터베이스 인스턴스와 연결합니다.

우선 VPC를 만들어 봅시다. AWS 콘솔에서 VPC로 이동하고 Create VPC를 선택합니다.

VPC의 이름을 선택하고 CIDR 범위를 지정합니다.

그런 다음, RDS 데이터베이스 전용 VPC 서브넷을 만듭니다. VPC 대시 보드 탐색 창에서 Subnets을 선택한 다음 Create subnet를 선택합니다.

서브넷의 이름을 설정하고 CIDR 범위 및 가용 영역을 지정합니다.

AWS 리전 내의 가용 영역 각각에 대해 이 단계를 반복하십시오. 이 블로그 예제인 AWS 리전의 경우 ap-southeast-2에는 3개의 가용 영역이 있습니다. 따라서 이 단계를 세 번 반복하여 각 가용 영역당 하나씩 총 세 개의 서브넷을 만듭니다. AWS 리전 내의 가용 영역 작업에 대한 자세한 내용은 Amazon EC2 설명서의 리전 및 가용 영역을 참조하십시오.

다음 단계는 아래 예제와 같이 데이터베이스의 서브넷을 서브넷 그룹이라는 Amazon RDS 구문에 추가하는 것입니다. 서브넷 그룹은 RDS 인스턴스가 배포된 서브넷 모음입니다. 자세한 내용은 RDS 설명서에서 DB 서브넷 그룹 작업을 참조하십시오.

AWS 콘솔에서 RDS로 이동하고 Create DB Subnet Group을 선택하여 새 서브넷 그룹을 만듭니다.

이제 우리가 만든 VPC와 서브넷 그룹을 데이터베이스 인스턴스와 연결하고 퍼블릭 접근성에 대해 아니요를 선택합니다. RDS 시작 마법사의 네트워크 및 보안 섹션에서 이 작업을 수행할 수 있습니다.

보안 그룹 및 네트워크 ACL

보안을 위해서는 보안 그룹과 네트워크 ACL도 중요하며, 아래에서는 이에 대해 설명합니다.

네트워크 ACL

네트워크 ACL을 사용하여 보안 영역 모델링을 구현합니다(네트워크 ACL 작업에 대한 자세한 내용은 VPC 설명서의 네트워크 ACL 참조). 보안 영역은 비슷한 신뢰 수준의 자산을 포함하는 명확히 정의된 네트워크 경계를 제공합니다. 또한 보안 영역은 네트워크 트래픽 제어를 그 특성에 따라 보안 영역 안팎으로 정의하고 적용하기 위해 명확하고 간편한 추론을 가능하게 합니다.

다음은 보안 영역 모델링에 대한 한 가지 접근법을 나타내는 다이어그램입니다.

이 다이어그램의 모델에서 이전에 논리적으로 생성한 데이터베이스의 서브넷은 보안 영역에 속합니다. 네트워크 ACL을 만들어 적절한 네트워크 트래픽 제어를 적용해 봅시다. 네트워크 ACL은 상태가 없으므로 인바운드 및 아웃바운드 규칙을 모두 명시적으로 지정해야 합니다. 다음 예제에서 볼 수 있듯이 인바운드 및 아웃바운드 규칙은 데이터베이스 소비자에게 속하는 CIDR 범위 간에만 트래픽을 허용합니다. 애플리케이션 티어를 예로 들 수 있으며, 앞의 다이어그램에서는 내부(프라이빗) 영역으로 표시되었습니다.

또한 인바운드 트래픽은 Aurora MySQL에 구성된 포트로 제한됩니다(기본적으로 해당 포트는 3306). 다른 RDS 데이터베이스의 경우 해당 데이터베이스에 대해 구성된 포트를 사용합니다.

보안 영역 서브넷에 대한 네트워크 ACL을 만들려면 콘솔에서 VPC로 이동하고 Network ACL을 선택하십시오.

참고: 다른 보안 영역에 속한 서브넷에 대해서도 비슷한 단계를 수행하십시오.

참고: MySQL 클라이언트가 데이터베이스와 통신하는 데 사용되는 임시 포트 범위의 트래픽을 허용하도록 네트워크 ACL 아웃바운드 규칙을 설정하십시오. 또한 Microsoft SQL Server의 Active Directory 트래픽과 같은 데이터 복제 또는 관리 트래픽을 위해 추가 포트에서 트래픽을 허용하는 규칙을 설정하십시오.

다음 예제처럼 보안 영역 네트워크 ACL을 데이터베이스가 배포된 서브넷과 연결하십시오.

보안 영역을 구성하는 서브넷은 앞의 보안 영역 모델링 다이어그램과 같이 계층형 보안 영역 모델의 일부에 해당합니다. 보안 영역과 상호 작용하거나 서로 상호 작용하는 애플리케이션 계층을 호스팅할 추가 보안 영역을 만듭니다. 애플리케이션 계층 보안 영역은 자체 네트워크 ACL을 통해 네트워크 트래픽을 필터링하여 보안 영역에 대해 추가 수준의 격리를 제공합니다.

보안 그룹

데이터베이스의 서브넷에 대해 네트워크 ACL을 이미 정의한 경우 데이터베이스에 보안 그룹이 필요한 이유는 무엇입니까? 보안 그룹을 사용하여 계층화된 보안 디자인과 데이터베이스의 마이크로세그멘테이션을 만듭니다. 보안 그룹 작업에 대한 자세한 내용은 VPC 설명서의 VPC 보안 그룹을 참조하십시오.

애플리케이션 계층 – 앞의 다이어그램의 내부(프라이빗) 영역 – 내부에 에 두 개의 마이크로서비스가 있고 데이터베이스 계층(보안 영역) 내부에 해당 데이터베이스가 두 개 있다고 가정해 보겠습니다. 각 데이터베이스는 두 개의 마이크로서비스 중 하나와 연결됩니다.

두 가지 마이크로서비스는 네트워크 ACL을 통해 데이터베이스 트래픽을 보안 영역으로 전송합니다. 마이크로서비스 1이 마이크로서비스 2의 데이터베이스로 트래픽을 보내는 것을 방지하려면 어떻게 해야 합니까? 개별 보안 그룹을 두 데이터베이스 각각에 연결하고 데이터베이스를 소유한 해당 마이크로서비스의 트래픽만 활성화하여 이 작업을 수행할 수 있습니다. 다음 다이어그램은 이 마이크로세그먼테이션을 보여줍니다.

다음 예제는 해당 마이크로서비스의 보안 그룹이 될 수 있는 전용 보안 그룹에서만 허용된 인바운드 트래픽을 구성하여 이를 설명합니다. 시작하려면 콘솔에서 VPC로 이동하여 보안 그룹을 선택하십시오.

RDS 데이터베이스 인스턴스를 시작할 때 이 보안 그룹을 연결하려면 네트워크 및 보안으로 이동하십시오. 데이터베이스 인스턴스를 위해 만든 보안 그룹을 선택하십시오.

IAM을 통한 권한 제어

AWS Identity and Access Management(IAM)는 AWS를 구축하는 고객이 사용할 수 있는 기본적인 제어 기능입니다. 이는 AWS Well Architected Framework의 보안 축에 대한 5가지 모범 사례 중 첫 번째 사례에 해당합니다. 이 프레임워크를 사용하면 클라우드에서 안정적이고 안전하며, 효율성이 높고 비용 효율적인 시스템을 설계하고 운영하기 위한 아키텍처 모범 사례를 학습할 수 있습니다.

IAM를 이용한 작업을 시작하기 위해 제어 평면 작업에 대한 액세스 요구 사항을 데이터 평면 작업에 대한 액세스 요구 사항과 분리합니다.

권한 제어 작업

RDS의 경우, CreateDBInstance, ModifyDBInstance 및 CreateDBParameterGroup과 같은 RDS 인스턴스의 관리 기능을 참조합니다. 이 기능들은 권한이 높은 작업이므로 관련 권한을 사용자 또는 역할에 할당할 때 신중하고 엄격하게 작업해야 합니다.

다음은 지정된 데이터베이스 인스턴스에 제한된 관리 작업 세트를 부여하는 예제 IAM 정책입니다. 이 정책을 사용자, 그룹 또는 역할에 첨부할 수 있습니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "LimitedAdmin",
            "Effect": "Allow",
            "Action": [
                "rds:CreateDBSnapshot",
                "rds:StopDBInstance",
                "rds:StartDBInstance"
            ],
            "Resource": [
                "arn:aws:rds:[your_region]:[your_AWS_account_id]:snapshot:*",
                "arn:aws:rds:[your_region]:[your_AWS_account_id]:db:demoDB"
            ]
        },
        {
            "Sid": "DescribeInstances",
            "Effect": "Allow",
            "Action": "rds:DescribeDBInstances",
            "Resource": "*"
        }
    ]
}

데이터 제어 작업

데이터 제어 작업은 일반적으로 데이터베이스의 데이터를 선택, 삽입, 수정 및 삭제하는 작업을 의미합니다. Amazon RDS 데이터베이스에서 데이터 평면 작업을 수행하는 곳은 두 부분이 있습니다.

데이터베이스 인증
데이터베이스 액세스 제어

첫 번째 부분은 누가 데이터베이스에 액세스할 수 있는지 인증하는 것입니다. 데이터베이스 내에서 인증을 설정할 수 있습니다. 아니면 MySQL 또는 PostgreSQL과 호환되는 Amazon Aurora 또는 RDS for MySQL 또는 PostgreSQL를 사용하는 경우 IAM 통합을 사용하여 인증을 설정할 수 있습니다.

두 번째 부분은 액세스 제어입니다. 즉, 데이터베이스 사용자가 어떤 수준의 액세스 권한을 갖는지 결정합니다. 데이터베이스 내에서 액세스 제어를 정의합니다.

데이터베이스 인증 – 먼저 데이터 평면 작업에 대한 인증을 설정하는 방법을 살펴 보겠습니다.

인증 옵션 1은 IAM 데이터베이스 인증을 사용하는 것입니다. 이 방법을 사용하려면 새 RDS 데이터베이스 인스턴스를 시작할 때 IAM DB 인증 활성화를 선택합니다.

마스터 계정을 사용하여 데이터베이스 인스턴스에 연결하고 IAM 사용자 또는 역할을 위해 IAM 인증과 통합할 데이터베이스 계정을 만듭니다.

mysql --host=[your_AuroraMySQL_cluster_endpoint] --port=3306 --ssl-ca=rds-combined-ca-bundle.pem --user=master -p

CREATE USER [your_db_user] IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';

RDS 인스턴스에 연결할 수 있도록 IAM 정책을 추가합니다. 이 경우 Aurora 클러스터를 리소스로 선택하십시오.

AWS 콘솔에서 IAM로 이동하고 Policies를 선택합니다.

환경에 대한 정책 정의를 수정합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds-db:connect"
            ],
            "Resource": [
                "arn:aws:rds-db:[your_region]:[your_AWS_account_id]:dbuser:[your_AuroraMySQL_resourceId/[your_db_user]"
            ]
        }
    ]
}

이 정책의 Amazon 리소스 이름(ARN)에 대해 정의해야 할 주요 구성 요소를 식별해 봅시다. 주어진 ARN에서 “arn:aws:rds-db:ap-southeast-2:1234567890:dbuser:cluster-WIK2GTMJGD5K7F4OJJ2DLCV6CA/db_iam_user“는 주요 구성 요소입니다.

ap-southeast-2는 내 Aurora MySQL 클러스터가 생성된 AWS 리전입니다.
1234567890은 AWS 계정 번호를 나타냅니다.
cluster-WIK2GTMJGD5K7F4OJJ2DLCV6CA는 Aurora MySQL 클러스터 리소스 ID입니다.
db_iam_user는 Aurora MySQL에서 생성된 데이터베이스 사용자입니다.

참고: IAM 콘솔을 사용하여 정책을 만드는 경우 현재 콘솔은 rds-db : connect 작업을 사용하여 정책에 대한 오류를 표시합니다. 이 오류는 무시해도 됩니다.

마지막으로 이전 IAM 정책을 IAM 사용자 또는 역할에 첨부합니다. 이 예제에서는 IAM 사용자에 정책을 추가합니다.

이전 단계에서 작성한 정책은 rds-connect-policy로 명명됩니다.

IAM 정책 및 RDS 작업에 대한 자세한 단계는 RDS 설명서에서 IAM 데이터베이스 액세스를 위한 IAM 정책 생성 및 사용을 참조하십시오. IAM 인증을 사용하여 RDS에 연결하는 방법에 대한 단계별 안내서는 AWS 데이터베이스 블로그 게시물인 Use IAM authentication to connect with SQL Workbench/J to Amazon Aurora MySQL or Amazon RDS for MySQL을 참조하십시오.

인증 옵션 2는 기본 데이터베이스 인증 제어를 사용합니다.

예를 들어, 다음과 같은 데이터베이스 명령은 데이터베이스 엔진에 의해 인증된 사용자를 만듭니다.

CREATE USER db_user IDENTIFIED BY '<password>';

이 방법을 사용하는 경우 데이터베이스 비밀번호 교체 및 비밀번호에 대한 애플리케이션 액세스를 위해 AWS Secrets Manager를 사용할 것을 권장합니다. AWS Secrets Manager를 사용하면 애플리케이션 코드 또는 구성 내에 데이터베이스 암호를 하드 코딩할 필요가 없습니다. 또한 비밀번호 교체에 자동화 기능를 적용할 수 있습니다.

비밀번호 교체를 위해 AWS Secrets Manager를 사용하는 방법을 알아 보려면 AWS 보안 블로그 게시물인 How to use AWS Secrets Manager to rotate credentials for all Amazon RDS database types, including Oracle을 확인하십시오. AWS Secrets Manager는 AWS Lambda 함수를 사용하여 RDS 데이터베이스 비밀번호를 교체합니다. 이를 수행하기 위해 Lambda 함수가 사용하는 로직에 대한 자세한 내용은 Lambda 설명서의 Lambda 교체 함수 개요를 참조하십시오.

AWS Secrets Manager는 보안 암호가 교체되는 RDS 데이터베이스와 동일한 VPC 및 서브넷 그룹에 AWS Lambda 함수를 만듭니다. Lambda 함수가 생성된 후에는 관리 영역의 서브넷에 다시 첨부합니다 (앞의 보안 영역 모델링 다이어그램 참조).

데이터베이스 액세스 제어 – 사용자가 인증된 후 데이터베이스 엔진은 사용자가 테이블, 뷰, 저장된 프로시저 등과 같은 데이터베이스 리소스에 대한 사용자의 액세스 수준을 확인합니다. 미리 정의된 데이터베이스 역할을 할당하거나 개별 권한을 직접 부여하여 데이터베이스에서 액세스 수준을 구성합니다.

다음 명령은 사용자에게 데이터 조작 언어(DML) 액세스 권한을 부여하는 방법에 대한 예제입니다. 권한 부여는 사용자가 액세스 할 수 있는 데이터베이스 리소스를 지정하는 것입니다. 이것은 인증과는 별도로 사용자의 자격 증명을 확인하는 것과 관련이 있습니다. 따라서 사용자가 데이터베이스에서 인증했는지 또는 통합 IAM 인증을 사용했는지 여부에 관계없이 이 인증 프로세스는 동일하게 유지됩니다.

GRANT SELECT, INSERT, DELETE ON demoschema.* TO 'db_user';

암호화 및 토큰화

또한 데이터베이스 보안의 핵심은 다음과 같은 암호화 및 토큰화입니다.

유효 상태의 암호화

유효 상태의 암호화를 실행하는 것은 중요합니다. 이를 통해 데이터베이스 및 스냅샷 (암호화된 경우)의 기초가 되는 볼륨을 명시적으로 부여된 AWS KMS 암호화 키 사용 권한을 통해서만 AWS 계정 외부에서 읽을 수 있습니다.

모든 RDS 데이터베이스 엔진에서 유효 상태의 암호화를 사용하려면 RDS 데이터베이스 인스턴스를 만들 때 간단한 구성 옵션을 설정해야 합니다. 다음 내용은 Aurora MySQL에서 유효 상태의 암호화를 활성화하는 방법에 대한 예제입니다. RDS 인스턴스를 만든 후에는 유효 상태의 암호화를 활성화할 수 없으므로 데이터베이스 프로비저닝 프로세스에 통합되어 있는지 확인하십시오.

유효 상태의 RDS 암호화 외에도 특정 데이터베이스 엔진에 고유한 암호화 기능을 사용할 수도 있습니다. RDS SQL Server 및 RDS Oracle의 Transparent Data Encryption(TDE)과 SQL Server를 위한 SQL Server 상시 암호화 옵션이 예에 해당합니다.

다음과 같이 RDS 시작 마법사의 일부로 RDS 유효 상태의 암호화를 사용합니다.

전송 중 암호화

Amazon RDS는 각 RDS 데이터베이스에 대한 Secure Sockets Layer(SSL) 인증서를 자동으로 생성하여 SSL을 통한 클라이언트 연결을 활성화합니다. AWS 리전별 RDS SSL 인증서를 사용하여 애플리케이션이 올바른 AWS 리전의 RDS 인스턴스에 연결되어 있는지 확인하십시오. RDS 설명서의 SSL을 사용하여 DB 인스턴스에 대한 연결 암호화에서 개별 AWS 리전에 대한 리전 중간 인증서를 다운로드할 수 있는 링크를 찾을 수 있습니다.

참고: RDS Oracle 데이터베이스의 경우 RDS 설명서에 설명된대로 옵션 그룹에 Oracle SSL 옵션을 추가해야 합니다.

토큰화

토큰화는 민감한 데이터를 고유 식별자로 대체합니다. 이 식별자를 사용하여 다른 데이터 원본의 원래 민감한 데이터를 찾습니다. 반면, 암호화는 민감한 데이터에 암호를 적용하여 권한 있는 당사자만 읽을 수 있는 방식으로 데이터를 인코딩합니다.

토큰화는 높은 민감도 또는 PCI와 같은 특정 규정 준수 요구 사항이 있는 데이터의 특정 부분을 보호하는 데 도움이 되는 암호화의 대안입니다. 민감한 데이터를 전용 보안 데이터 저장소로 분리하고 대신 토큰을 사용하면 잠재적인 비용과 복잡성 증대를 방지할 수 있습니다. 또한 임시, 일회용 토큰을 사용하여 위험을 줄일 수 있습니다.

토큰화는 애플리케이션 레벨의 구현과 관련된 문제입니다. 일반적으로 전용 데이터 저장소를 사용해 토큰과 이에 대응되는 민감한 데이터 값 간의 매핑을 유지하여 토큰화를 구현합니다. 토큰은 민감한 데이터 값 대신 애플리케이션 데이터베이스에 저장되며 런타임 때 애플리케이션이 전용 토큰 데이터 저장소의 실제 값으로 대체됩니다.

다음 다이어그램은 토큰화 프로세스의 예제를 보여줍니다.

이 예제에는 다음과 같은 단계들이 포함됩니다.

이 애플리케이션은 신용카드 번호와 같은 민감한 데이터를 토큰화 API에 제공합니다.
토큰화 API는 애플리케이션 사용자의 인증을 요청합니다.
인증 API는 사용자를 인증합니다.
토큰화 API는 신용카드 번호에 대한 토큰을 생성하고 토큰 및 신용카드 번호를 토큰화 데이터베이스에 저장하고 링크합니다.
토큰화 API는 애플리케이션에 토큰을 반환합니다.
애플리케이션은 애플리케이션 데이터베이스에 신용카드 번호 대신 토큰을 저장합니다.

3. 감시 제어

아래 설명되는 감시 제어는 데이터베이스 보안을 위해 중요합니다.

무단 트래픽 감지

VPC 흐름 로그 및 AWS CloudTrail 로그를 사용자 지정 논리로 모니터링하여 이상값을 식별하는 것과 마찬가지로 인증되지 않은 트래픽을 감지할 수 있는 방법이 몇 가지 있습니다. VPC 플로우 로그에 대한 자세한 내용은 VPC 설명서의 VPC 흐름 로그를 참조하십시오. CloudTrail 로그에 대한 자세한 내용은 CloudTrail 설명서의 CloudTrail 로그 파일 작업을 참조하십시오.

또는 Amazon GuardDuty를 실행하여 사용자를 대신해 네트워크 트래픽을 모니터링하고 기계 학습을 적용하여 비정상적인 동작을 탐지하고 경고하도록 할 수 있습니다. 다음은 계정에서 Amazon GuardDuty를 활성화하는 방법입니다.

AWS 콘솔에서 Amazon GuardDuty로 이동하십시오. GuardDuty를 AWS 계정에 처음 사용하는 경우 다음 페이지가 나타납니다.

Enable GuardDuty를 선택하여 GuardDuty를 켭니다.

그런 다음, GuardDuty 결과를 모니터링하고 작동하는 CloudWatch 규칙을 생성합니다. Amazon SNS를 통해 알림 경고를 설정하고 Lambda를 통해 자동 해결 작업을 설정할 수도 있습니다.

다음 스크린샷은 SNS 주제로 이메일 경고를 보내는 구체화된 GuardDuty 이벤트에 대한 CloudWatch 규칙의 예를 보여줍니다.

이를 설정하려면 콘솔에서 CloudWatch를 탐색하고 규칙을 선택하여 새 규칙을 만듭니다. 그런 다음, 아래와 같은 단계를 따르십시오.

규칙 생성을 선택합니다.
이벤트 패턴이 선택되었는지 확인합니다.
목록에서 사용자 지정 이벤트 패턴 작성을 선택합니다.

다음과 같은 JSON을 사용자 지정 이벤트 창에 추가합니다.

{
  “source”: [
    “aws.guardduty”
  ],
 “detail”: {
   “type”: [
     “UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom”
     ]
   }
}

대상 섹션에서 대상 추가를 선택하여 CloudWatch 규칙에 대한 새 대상을 추가합니다.
목록에서 SNS 주제를 선택하고 Amazon SNS 주제 이름을 선택하십시오.

구성 드리프트

구성 드리프트에서 시스템의 현재 보안 구성은 원하는 강화 상태에서 벗어납니다. 구성 드리프트는 초기 배포 후 시스템 수정으로 인해 발생할 수 있습니다.

다음 예제는 AWS Config를 사용하여 기준선 설정에 대해 데이터베이스 구성을 지속적으로 모니터하고 구성이 기준선에서 벗어날 때 경고를 보냅니다.

이를 설정하려면 콘솔에서 AWS Config로 이동하고 규칙를 선택하여 새 AWS Config 규칙을 추가하십시오.

참고: AWS Config를 최초로 실행하는 경우 초기 설정 프로세스가 진행될 수 있습니다.

그런 다음, 아래와 같은 단계를 따르십시오.

규칙 추가를 선택합니다.
검색 상자에 RDS를 입력합니다.
실행하려는 RDS 구성 검사를 선택합니다.

RDS에 대해 사전정의된 규칙을 검색하거나 선택하고, 또는 새로운 사용자 지정 규칙을 만듭니다.

세분화된 감사

다음과 같이 데이터베이스 보안을 강화하기 위해 세분화된 감사를 추가로 수행할 수 있습니다.

권한 제어 작업

앞서 설명했듯이 RDS의 경우, 권한 제어 작업은 CreateDBInstance, ModifyDBInstance 및 CreateDBParameterGroup과 같은 RDS 인스턴스의 관리 기능을 참조하십시오. 모든 Amazon RDS 제어 평면 작업은 CloudTrail에 의해 기록되며 Amazon RDS API Reference에 문서화되어 있습니다.

CloudTrail에서 새로운 트레일을 생성하면 감사를 위해 모든 CloudTrail 로그를 Amazon S3에 저장할 수 있습니다. 자세한 내용은 AWS CloudTrail을 사용하여 Amazon RDS API 호출 로깅을 참조하십시오.

새로운 트레일을 생성하려면 콘솔에서 CloudTrail로 이동하여 트레일을 선택하십시오.

다음 스크린샷은 CloudTrail이 기록한 모든 RDS API 호출과 일치하고 사용자 지정 알림 또는 작업을 트리거할 수 있는 Amazon CloudWatch 규칙을 보여줍니다. 이 규칙을 만들려면 다음 단계를 따르십시오.

콘솔에서 Amazon CloudWatch로 이동합니다.
규칙을 선택하여 새로운 규칙을 만듭니다.
규칙 생성을 선택합니다.
이벤트 패턴이 선택되었는지 확인합니다.
목록에서 사용자 지정 이벤트 패턴 작성을 선택합니다.
서비스 이름에 대해 Relational Database Service(RDS)를 선택합니다.
이벤트 유형의 경우 CloudTrail을 통한 AWS API 호출을 선택합니다.
임의 작업을 선택합니다.
대상 섹션에서 대상 추가를 선택하여 CloudWatch 규칙에 대한 새 대상을 추가합니다.
목록에서 SNS 주제를 선택하고 Amazon SNS 주제 이름을 선택하십시오.

데이터 제어 작업

다시 설명하지만, 데이터 제어 작업은 일반적으로 데이터베이스의 데이터를 선택, 삽입, 수정 및 삭제하는 작업을 의미합니다. Aurora MySQL에서는 Aurora DB 클러스터 파라미터 그룹에서 고급 감사 기능을 활성화하여 데이터 평면 작업을 추적할 수 있습니다. 데이터베이스 파라미터 그룹은 하나 이상의 데이터베이스 인스턴스에 적용되는 엔진 구성 값의 컨테이너 역할을 합니다.

다음 내용은 Aurora MySQL에서 고급 감사 기능을 활성화하는 방법에 대한 예제입니다. 자세한 내용은 Aurora 설명서의 Amazon Aurora MySQL DB 클러스터에서 고급 감사 사용을 참조하십시오.

콘솔에서 RDS로 이동하고 파라미터 그룹을 선택하여 새 파라미터 그룹을 만듭니다.

Aurora 클러스터에 대한 사용자 지정 파라미터 그룹을 생성합니다.

사용자 지정 파라미터 그룹을 수정하여 server_audit_logging을 실행합니다.

사용자 지정 파라미터 그룹을 수정하여 CloudWatch로 로그를 내보냅니다. CloudWatch 로그 작업을 통해 사용자 지정 알림 및 작업을 생성할 수 있습니다. 이 작업을 수행하려면 적절한 CloudWatch 로그 액세스 역할을 클러스터 파라미터에 연결해야 합니다. 자세한 내용은 Aurora 설명서의 Amazon CloudWatch Logs에 Amazon Aurora MySQL 로그 게시에서 확인할 수 있습니다.

마지막으로 데이터베이스 인스턴스를 시작할 때 이 사용자 지정 클러스터 파라미터 그룹을 Aurora MySQL 클러스터와 연결합니다.

다른 RDS 데이터베이스 엔진에서 자세한 감사 로깅을 사용하는 방법에 대한 자세한 내용은 다음 설명서 항목을 참조하십시오.

요약

이 게시물에서는 일반적인 DB 보안 패턴을 RDS 데이터베이스에 적용하는 방법을 설명합니다. 이를 통해 민감한 데이터를 중심으로 강력한 보안 상태를 만들 수 있습니다.

또한 이 게시물에서는 계층화된 접근을 통해 심층 방어를 만드는 방법을 이용해 RDS 데이터베이스를 보호하는 방법도 소개합니다. 이 방법은 VPC 내의 네트워크 ACL 및 서브넷을 통해 네트워크 보안 영역을 사용합니다.

또한 AWS 네트워킹, IAM 및 데이터베이스 서비스 내에서 AWS 예방 보안 제어 기능을 결합하는 방법에 대해서도 다룰 것입니다. Amazon GuardDuty, AWS Config 및 AWS CloudTrail을 사용하여 감시 제어를 설정하는 방법을 설명하여 데이터에 대한 심층 방어를 활성화하도록 합니다.

좀 더 자세한 것은 Amazon RDS 보안 페이지를 참고해 주시기 바랍니다.

Syed Jaffry는 Amazon Web Services의 솔루션 아키텍트입니다. 그는 금융 서비스 고객과 협력하여 클라우드에서 안전하고 복원력이 뛰어나고 확장 가능한 고성능 응용 프로그램을 배포할 수 있도록 지원합니다.

Source: Amazon RDS에서 민감한 데이터 보안을 위한 모범 사례

지락문화예술공작단

Amazon RDS에서 민감한 데이터 보안을 위한 모범 사례

1. 데이터 분류 및 보안 영역 모델링

데이터 분류

보안 영역 모델링

2. 심층 방어

기본 보안 설정

예방 제어

DDOS 보호

애플리케이션 레벨 위협 예방

AWS WAF

데이터베이스 방화벽

네트워크 격리

보안 그룹 및 네트워크 ACL

네트워크 ACL

보안 그룹

IAM을 통한 권한 제어

권한 제어 작업

데이터 제어 작업

암호화 및 토큰화

유효 상태의 암호화

전송 중 암호화

토큰화

3. 감시 제어

무단 트래픽 감지

구성 드리프트

세분화된 감사

권한 제어 작업

데이터 제어 작업

요약

Be the first to comment

Leave a Reply 응답 취소