AWS Config와 Systems Manager를 활용하여 인터넷에 연결된 로드 밸런서 생성 탐지 및 제거하기

AWS 서비스를 이용하다보면 특정 서비스의 구성을 조직의 규정을 준수하기 위하여 제한하는 경우가 많이 발생합니다. 그리고 이러한 제한된 구성을 각 조직의 구성원들이 준수할 수 있도록 사용하는 첫번째 방법 중의 하나가 AWS Identity and Access Management (IAM) 서비스를 이용하여 IAM 사용자나 역할에 제한된 권한을 부여하는 것입니다. 예를 들면, 특정 VPC 에는 Internet Gateway 의 생성을 제한하여 해당 VPC 가 인터넷으로 연결되는 것을 제한하고자 한다면 SCP(Service Control Policy)나 IAM Policy 등을 이용하여 각 사용자에게 인터넷 게이트웨이(Internet Gateway)를 생성하는 권한을 제한하는 방법을 통해 목적하는 바를 이룰 수 있습니다.

하지만 AWS 서비스를 이용하다보면 이처럼 조직에서 원하는 제한에 대한 요구사항을 IAM 정책을 사용하는 것 만으로는 구현할 수 없는 경우가 발생하게 됩니다. 예를 들면, 이 글에서 다룰 “인터넷에 연결된 ALB (Internet-Facing Application Load Balancer)의 생성 제한” 과 같은 독특한 요구 사항이 있을 수 있습니다. 조직에서는 보안적인 이유로 특정 계정이나 특정 VPC 에서 Internet-Facing ALB 의 생성을 제한하고자 하려고 한다고 가정해 보겠습니다. 그럼 이와 같은 요구 사항은 IAM 이나 SCP 정책을 통해 구현이 가능할까요?

결론부터 말씀드리면 IAM 이나 SCP 정책을 통해서는 ALB 를 생성할 때 구성 옵션이 Internet-facing 인 것만을 차단하는 정책은 구성할 수 없습니다. 따라서, 이런 요구 사항을 만족하기 위해서는 IAM 이나 SCP 정책 이외의 접근 방법이 필요하고 그 방법으로 AWS Config와 AWS Systems Manager 의 조합을 설명드리도록 하겠습니다.

AWS Config는 AWS 서비스의 설정 내역을 검사 및 추적하여 각 AWS 자원의 연관 관계에 대한 정보를 제공합니다. 또한, AWS Config 규칙을 이용하여 관리자가 지정한 규칙을 준수하는지 여부를 검사하여 조직 내에서 사용되고 있는 AWS 자원에 대한 규정 준수 여부를 확인합니다. 필요한 경우 수동 혹은 자동화된 방법에 의한 문제 해결 기능을 제공하고 있습니다.

따라서, AWS Config 규칙을 활용하면 특정 계정 내부 혹은 특정 VPC 에서 Internet-facing ALB 가 생성되는 경우 이를 탐지하는 것이 가능합니다. 그리고 AWS Config 규칙에는 수동 혹은 자동 문제해결 기능을 제공하는데 Internet-facing ALB 의 생성이 탐지되는 경우 자동으로 해당 ALB 를 삭제하도록 자동 문제 해결 기능을 사용하면 허용되지 않은 Internet-facing ALB 가 생성 되었을 때 즉시 해당 ALB 가 삭제 되도록 구성할 수 있습니다.

이 글에서는 좀 더 편리한 AWS Config 규칙의 생성 및 적용을 위하여 RDK(Rule Development Kit) 를 이용하도록 하겠습니다. 아래의 절차를 따라 RDK 를 설치한 후 Internet-facing ALB 생성 여부를 탐지하는 규칙을 생성 및 적용하도록 하겠습니다.

1. RDK 설치 및 규칙 생성

RDK 설치
Cloud9 이나 Windows 혹은 Mac 등에서 아래의 명령을 이용하여 RDK 를 설치하도록 합니다.

$ pip install rdk

참고 1.이 글에서는 Cloud9 (서울 리전, Amazon Linux2)에 RDK 를 설치하였습니다.
참고 2. RDK 사용을 위한 IAM 최소 권한은 링크를 참고하시기 바랍니다.
참고 3. 이 글처럼 서울리전(ap-northeast-2)에서 Cloud9 을 사용하는 경우 AWS Managed Temporary Credential 을 비활성화 후 Instance Profile 을 사용하거나 AWS CLI 에 자격증명을 별도로 입력하여 사용하시기 바랍니다.

RDK 가 정상적으로 설치되었다면 Config 규칙이 생성될 Region을 지정하도록 합니다.

$ export AWS_DEFAULT_REGION=ap-northeast-2

이제 모든 준비가 끝났습니다. Config 규칙을 생성을 위하여 아래의 명령을 이용하여 RDK 를 초기화하도록 하겠습니다.

$ rdk init

Config 규칙을 생성하기 위해서는 규칙에서 검사하고자하는 AWS 자원의 CI(Configuration Item) 구조를 파악하여야 합니다. 이 글에서 생성하고자하는 규칙은 ALB(Application Load Balancer) 와 관련한 규칙이므로 ALB 의 Resource Type 을 먼저 찾아보도록 하겠습니다. Config 에서 지원하는 리소스 유형 페이지에서 리소스를 찾아보니 ALB 와 관련한 리소스 유형 값이 “AWS::ElasticLoadBalancingV2::LoadBalancer” 라는 것을 발견하였습니다.

ALB 의 리소스 유형을 알았으니 이제 ALB 의 CI(Configuration Item)를 확인해보도록 하겠습니다. RDK 에서는 각 리소스 유형의 CI 를 바로 확인할 수 있는 명령을 제공하고 있습니다. RDK 의 편리한 점 중 하나라고 볼 수 있는데요. 아래의 명령을 입력하여 ALB CI 를 확인하도록 하겠습니다.
rdk sample-ci AWS::ElasticLoadBalancingV2::LoadBalancer
RDK 의 Sample CI 확인 명령이 정상적으로 실행되면 아래와 같이 지정한 리소스 유형의 CI 샘플을 출력할 수 있습니다.

{
    "version": "1.2",
    "accountId": "123456789012",
    "configurationItemCaptureTime": "2016-11-11T02:22:46.556Z",
    "configurationItemStatus": "ResourceDiscovered",
    "configurationStateId": "1478830966556",
    "configurationItemMD5Hash": "c7647c4051b0d45ded82997c2e964cef",
    "arn": "arn:aws:elasticloadbalancing:us-east-1: 123456789012:loadbalancer/app/MyALB/268aa84731d12345",
    "resourceType": "AWS::ElasticLoadBalancingV2::LoadBalancer",
    "resourceId": "arn:aws:elasticloadbalancing:us-east-1: 123456789012:loadbalancer/app/MyALB/268aa84731d12345",
    "resourceName": "MyALB",
    "awsRegion": "us-east-1",
    "availabilityZone": "Multiple Availability Zones",
    "resourceCreationTime": "2016-11-11T02:13:38.770Z",
    "tags": {},
    "relatedEvents": [
        "6cfc8538-2fb0-4e90-b3b5-82d12345cbc4"
    ],
    "relationships": [
        {
            "resourceType": "AWS::EC2::SecurityGroup",
            "resourceId": "sg-2ed0d557",
            "relationshipName": "Is associated with SecurityGroup"
        },
        {
                  ...
    ],
    "configuration": {
        "loadBalancerArn": "arn:aws:elasticloadbalancing:us-east-1: 123456789012:loadbalancer/app/MyALB/268aa84731d32825",
        "dNSName": "MyALB-123456789012.us-east-1.elb.amazonaws.com",
        "canonicalHostedZoneId": "Z35SXDOTRQ7X7K",
        "createdTime": "2016-11-11T02:13:38.770Z",
        "loadBalancerName": "MyALB",
        "scheme": "internet-facing",
        "vpcId": "vpc-0990dc6d",
        "state": {
            "code": "active"
        },
                  ...
        ],
        "Tags": []
    }
}

출력된 ALB CI 의 내용을 자세히 살펴보면 "scheme": "internet-facing" 이란 내용이 있는 것을 확인할 수 있습니다. 즉, 우리는 생성된 ALB 의 속성에 “scheme” 라는 것이 있고 그 값이 “internet-facing” 인 경우 Internet-facing ALB 라는 것을 유추할 수 있습니다. 따라서, 우리가 생성할 AWS Config 규칙은 “scheme” 의 값을 검사하여 그 값이 “internal” 이면 “compliant”, 그렇지 않으면 “non-compliant” 하다는 판단을 내리도록 하면 됩니다.
그럼 이제 아래의 명령을 입력하여 RDK 를 이용한 ALB 에 대한 샘플 규칙을 생성하도록 하겠습니다.
$ rdk create restrict-internet-alb --runtime python3.8 --resource-types AWS::ElasticLoadBalancingV2::LoadBalancer --input-parameters '{"desiredscheme":"internal"}'

RDK Create 명령이 정상적으로 완료되면 아래 화면과 같이 지정한 Config 규칙의 이름과 동일한 디렉토리가 생성되고 몇 가지 파일이 자동으로 생성되는 것을 확인할 수 있습니다.

“단계 7”을 통해 RDK 에서 생성한 폴더 및 파일 중 “parameters.json” 파일의 내용을 보면 ALB(AWS::ElasticLoadBalancingV2::LoadBalancer)를 SourceEvent 로 하여 Parameter 값이 “desiredscheme: internal” 로 설정되어 있는 것을 볼 수 있습니다.

이제 Config 규칙 생성을 위하여 restrict-internet-alb 디렉토리의 파일 중 restrict-internet-alb.py 파일을 수정하도록 하겠습니다. restrict-internet-alb.py 파일을 RDK 를 이용하여 Config 규칙을 생성할 때 Lambda 함수에 해당하는 내용이 포함되기 때문에 특정 규칙에 대한 Compliant/Non_Compliant 여부를 이곳에서 정의해주면 됩니다. restrict-internet-alb.py 문서를 열어 54번째줄에 있는 “return “NOT_APPLICABLE” 을 삭제하고 아래의 내용을 붙여넣도록 하겠습니다. 아래의 내용은 CI 중 “Scheme” 의 값이 “DesiredScheme” 의 값과 동일하면 “COMPLIANT” 그렇지 않으면 “NON_COMPLIANT” 로 판단하도록 설정한 것입니다.
```
if configuration_item['resourceType'] !='AWS::ElasticLoadBalancingV2::LoadBalancer':
return 'NOT_APPLICABLE'
if configuration_item['configuration']['scheme'] == valid_rule_parameters['desiredscheme']:
return 'COMPLIANT'
return 'NON_COMPLIANT'
```

RDK 로 생성한 규칙을 적용하기 전에 아래의 명령을 이용하여 규칙의 에러 유무를 확인하도록 하겠습니다.

$ rdk test-local restrict-internet-alb

위 그림과 같이 “OK” 가 출력된다면 RDK 로 생성한 규칙을 정상적으로 적용할 수 있는 준비가 된 것입니다. 이제 아래의 명령을 이용하여 RDK 에서 생성한 규칙을 계정에 적용하도록 하겠습니다.

$ rdk deploy restrict-internet-alb

RDK 규칙이 생성 완료되는데는 약간의 시간이 소요됩니다. 위 그림과 같이 “Config Deploy Complete” 메시지가 출력되었다면 정상적으로 Config 규칙이 생성되었음을 의미합니다.

2. Config 규칙 확인

AWS Config 메뉴에서 아래와 같이 RDK 를 통해 생성한 규칙이 정상적으로 생성되어 있는 것을 확인하였습니다.

아래와 같이 생성된 Config 규칙을 클릭하여 화면 하단의 “Resources in scope” 메뉴를 “All” 로 변경한 후 매칭된 자원이 있는지 확인합니다.
*제가 진행한 테스트 환경에서는 ALB 가 생성되지 않은 상태이기 때문에 아무런 ALB 가 나타나지 않습니다.

3. Config 규칙 동작 확인

RDK 에서 생성한 규칙이 정상적으로 반영된 것을 확인하였으니 이제 해당 규칙이 정상적으로 동작하는지 확인해보도록 하겠습니다. 간단한 테스트를 위해 아래와 같이 “Internet-facing” ALB 를 생성한 후 Config 규칙을 확인해보록 하겠습니다.

Config 규칙에서 확인해보니 아래와 같이 윗 단계에서 “Internet-facing” ALB 가 생성된 후 해당 ALB 가 Noncompliant 로 탐지된 것을 확인할 수 있습니다. 즉, 우리가 의도한대로 Config 규칙이 ALB 의 Scheme 를 검사하여 탐지 결과를 알려주는 것을 볼 수 있었습니다.

4. 문제 해결

Config 규칙은 관리자가 지정한 규칙을 기반으로하여 규정 준수여부를 확인하는 것 뿐만 아니라 규정을 준수하지 않은 자원에 대한 문제 해결작업까지 구성하는 기능을 제공하고 있습니다. 이번에는 이 기능을 활용하여 윗 단계에서 생성한 규칙에서 탐지된 Noncompiant ALB 자원을 삭제하는 설정을 적용해보도록 하겠습니다.

Config 에서의 문제해결은 Systems Manager 의 Document 를 통해서 수행됩니다. 따라서, 규정을 준수하지 않는 자원에 대한 문제 해결을 위해서는 Document 를 별도로 생성하여야 합니다. 아래의 절차에 따라 Document 를 생성하도록 하겠습니다.

4.1 Document 생성

1. Systems Manager 의 Document 메뉴에서 새로운 Document 를 생성하여 아래의 값을 입력하도록 합니다.

Assume Role - {{ AutomationAssumeRole }}

Parameter Name - AutomationAssumeRole

Allowed Pattern - ^arn:aws(-cn|-us-gov)?:iam::\d{12}:role\/[\w+=,.@_\/-]+|^$

Parameter Name - LoadBalancerArn

1. Step 1 에서 아래와 같이 각 항목에 값을 입력하도록 합니다.
2. 모든 값을 입력하였다면 아래와 같이 Systems Manager -> Documents -> Owned by me 에 생성된 Document 를 확인할 수 있습니다.

4.2 수동 문제 해결

문제 해결에 사용할 Document 까지 정상적으로 생성하였다면 이제 Config 규칙에서 생성한 Document 를 통해 문제를 해결 할 수 있습니다. 문제 해결 방법은 수동 혹은 자동으로 구성할 수 있습니다. 먼저 수동 문제 해결방법을 살펴보도록 하겠습니다. 수동 문제 해결을 설정하기 위해서 Config 규칙의 세부 메뉴에서 우측 상단의 “Actions” 를 클릭하여 “Manage remediation” 을 클릭합니다.

아래와 같이 문제 해결 방식을 “Manual remediation” 을 선택한 후 “Remediation Action Details” 에서 이전 과정에서 생성한 Document 를 선택합니다.

아래와 같이 “Resource ID Parameter” LoadBalancerArn” 을 선택합니다.

아래와 같이 Parameters 의 값들이 선택된 것을 확인한 후 저장하도록 하겠습니다.

문제해결을 위한 Document 지정이 완료되었으니 아래와 같이 규정을 준수하지 않은 ALB 자원을 선택한 후 “Remediate” 버튼을 클릭해보도록 하겠습니다.

정상적이라면 아래와 같이 Status 가 “Action executed successfully” 로 나타나는 것을 확인할 수 있습니다. 잠시 후 EC2 의 Load Balancer 메뉴를 확인하면 Demo-InternetALB 가 삭제된 것을 확인할 수 있습니다.

4.3 자동 문제 해결

이번에는 관리자가 개입하여 수동으로 문제를 해결하는 것이 아니라 지정한 Document 를 통하여 규정을 준수하지 않는 자원을 식별한 경우 자동으로 문제 해결이 이뤄질 수 있도록 설정해보도록 하겠습니다.

1. 자동 문제 해결을 위해서는 수동 문제해결과 다르게 Automation Service Role 생성이 필요합니다. Automation Service Role 생성에 필요한 절차 를 참조하여 Automation Service Role 생성한 후 아래와 같이 생성된 AutomationServiceRole 의 ARN 을 복사합니다.

1. AutomationServiceRole 에서 ALB 를 삭제할 수 있도록 아래와 같은 Inline 정책을 추가하여 ALB 삭제 권한을 부여합니다.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticloadbalancing:DeleteLoadBalancer"
],
"Resource": "*"
}
]
}

1. Config Rule 의 Remediation Action 메뉴에서 아래와 같이 Edit 를 클릭한 후 이번에는Automatic remediation 을 선택합니다.
2. 다른 값은 기존과 동일하며 Parameters 의 값 중 AutomationAssumeRole 의 값만 단계 1에서 생성하여 복사해두었던 Automation Service Role 의 ARN 을 입력한 후 저장합니다.

1. 자동 문제 해결의 설정이 잘 동작하는지 확인하기 위하여 Interfa-facing ALB 를 다시 생성해보도록 하겠습니다. 아래와 같이 윗 단계에서 생성한 것과 동일한 설정으로 ALB 를 생성합니다.

Interenet-facing ALB 가 정상적으로 생성되면 ALB 생성 완료 몇 분 후 아래와 같이 Config 규칙에 생성된 Internet-facing ALB 가 Noncompliant 리소스로 탐지된 것을 확인할 수 있습니다.

Internet-facing ALB 가 Noncompliant 로 탐지되고 몇 분 후 아래와 같이 문제 해결이 정상적으로 실행되는 것도 확인할 수 있습니다.

EC2 메뉴로 이동하여 ALB 를 확인해본다면 ALB 역시 삭제되어 있는 것을 확인할 수 있습니다.

마무리

AWS 환경에서의 거버넌스 수립과 여러가지 서비스의 규정 준수는 안전한 클라우드 이용환경을 위하여 가장 기본적으로 전제되어야 하는 요구 사항입니다. 이와 같은 요구 사항은 AWS Config 를 통하여 수립하고 준수 여부를 확인할 수 있습니다. 이 과정에서 여러분들은 RDK 와 같은 도구를 사용하여 거버넌스 준수 여부에 필요한 규칙을 쉽고 편리하게 생성하실 수도 있습니다. 그리고 필요한 경우 문제 해결 기능을 통해 수동 혹은 자동으로 규정을 준수하지 않는 자원에 대한 조치를 수행할 수 있다는 것을 알 수 있었습니다.

이 글에서 다룬 시나리오는 RDK 를 이용하여 구성할 수 있는 다양한 Config 규칙의 한 시나리오에 지나지 않으며 여러분의 조직에서 필요한 다양하고 복잡한 요구사항의 시나리오 역시 RDK 를 통해 구현하실 수 있다는 점을 말씀드리고 싶습니다.

AWS 기술 블로그