빗썸의 AWS Systems Manager를 활용한 전사 EC2 보안 진단 자동화 구축 사례 2부: 중앙화된 EC2 보안 진단 자동화 아키텍처 구축

빗썸은 2014년 서비스 개시 이후, 전 세계 거래량 1위를 기록하며 신뢰받는 가상자산 거래소로 성장했습니다. 과거에는 가상자산 거래 플랫폼 구축, 운영, 블록체인 기술 분야에서 세계 최고 수준의 경쟁력과 노하우를 쌓았다면, 앞으로는 글로벌 디지털 금융 플랫폼의 미래를 선도하고자 합니다. 또한, 빗썸 보안실에선 최첨단 보안 시스템을 바탕으로 사용자 자산 보호와 거래 안전성을 최우선으로 보장하고 있습니다.

빗썸과 같이 EC2 인스턴스 기반의 워크로드를 운영하고 있는 환경에서 EC2 인스턴스의 취약점 점검은 매우 중요한 과제입니다. 클라우드의 장점인 유연하게 확장되는 EC2 인스턴스를 안전하게 사용하기 위해 취약점 점검을 수동이 아닌 자동으로 진행할 필요성이 있었습니다. 이에 빗썸에서는 내부 보안 규정을 준수하기 위하여 AWS Systems Manager Run Command를 이용하여 자동화된 보안 점검 시스템을 구축하게 되었습니다.

앞 선 첫 번째 블로그 글에 이어 이번 두 번째 블로그 글에서는 다중 계정 환경에서 중앙 계정의 Lambda 함수를 통해 다수의 멤버 계정에 있는 EC2 인스턴스들을 대상으로 Systems Manager (SSM) RunCommand 기능을 동작시킴으로써 EC2 보안진단 수행을 자동화하고, 진단결과를 중앙 S3 버킷으로 업로드하여 관리할 수 있도록 하는 아키텍처를 구축한 사례를 소개합니다.

• 1부 : 이벤트 기반의 EC2 권한 관리 자동화
• 2부 : 중앙화된 EC2 보안 진단 자동화 아키텍처 구축

1. SSM Command 문서 작성 및 중앙관리 방안

빗썸에서는 EC2 내 수행이 필요한 스크립트를 중앙 계정에서 SSM에서 Command 유형의 문서 스키마에 따라 작성한 후 멤버 계정들에 공유하여 배포하는 방식을 채택 했습니다. 이에 Command 문서에 대한 중앙 관리가 가능해졌으며, 명령 수행 단계를 세분화하여 명령 수행이 실패한 경우 어느 과정에서 실패했는지 가시성을 확보할 수 있게 되었습니다.

또한 Command 문서의 parameters 필드를 통해 Command 수행 시 취약점 점검 스크립트의 URL을 인스턴스에 전달할 수 있도록 구성했으며 allowPattern을 통해 허용된 위치에서 생성된 URL만 인스턴스 단에 전달 가능하도록 통제하는 절차를 구현했습니다.

• 중앙 계정에서 AWS SSM 문서에서 제공하는 aws:runShellScript 유형의 동작을 활용하여 커맨드를 작성합니다.
• 중앙 계정에서 AWS SSM 문서를 멤버 계정에 공유합니다.

다음 항목들을 통해서 문서의 주요 부분을 확인하실 수 있습니다.

• 파라미터 선언 부분

  {
    "parameters": {
      "scriptUrl": {
        "type": "String",
        "description": "URL for the script to be downloaded",
        "allowedPattern": "^https:\\/\\/bucketname\\.s3\\.ap-northeast-2\\.amazonaws\\.com\\/.*$"
      },
      "uploadUrl": {
        "type": "String",
        "description": "URL for the script to be uploaded",
        "allowedPattern": "^https:\\/\\/bucketname\\.s3\\.ap-northeast-2\\.amazonaws\\.com\\/.*$"
      },
      "workingDirectory": {
        "type": "String",
        "description": "(Optional) The path to the working directory on your instance.",
        "allowedPattern": "^\\/tmp\\/runcommand_script./*$"
      }
    }
  }

• 점검 스크립트 다운로드 단계

  {
    "action": "aws:runShellScript",
    "name": "Download_CCE_Script",
    "precondition": {
      "StringEquals": [
        "platformType",
        "Linux"
      ]
    },
    "maxAttempts": 3,
    "inputs": {
      "workingDirectory": "{{ workingDirectory }}",
      "runCommand": [
        "#!/bin/bash",
        "#################################################",
        "# Get CCE Script",
        "#################################################",
        "curl -o script.tar '{{ scriptUrl }}'",
        "curl -sS -w \"%{http_code}\" -o {{ workingDirectory }}/script.tar '{{ scriptUrl }}'",
        "tar -xf script.tar"
      ]
    }
  }

• 점검 스크립트 실행 단계

  {
    "action": "aws:runShellScript",
    "name": "Run_CCE_Script",
    "maxAttempts": 1,
    "precondition": {
      "StringEquals": [
        "platformType",
        "Linux"
      ]
    },
    "inputs": {
      "workingDirectory": "{{ workingDirectory }}",
      "runCommand": [
        "#!/bin/bash",
        "#################################################",
        "# RUN CCE Script",
        "#################################################",
        "source script.sh"
      ]
    }
  }

• 점검 결과 S3 업로드 단계

  {
    "action": "aws:runShellScript",
    "name": "Upload_result",
    "maxAttempts": 3,
    "precondition": {
      "StringEquals": [
        "platformType",
        "Linux"
      ]
    },
    "inputs": {
      "workingDirectory": "{{ workingDirectory }}",
      "runCommand": [
        "#!/bin/bash",
        "#################################################",
        "# Upload Result",
        "#################################################",
        "hostname=$(hostname)",
        "result=\"${hostname}.tar\"",
        "curl -sS -w \"%{http_code}\" -X PUT -T \"$result\" \"{{ uploadUrl }}\""
      ]
    }
  }

2. 중앙 계정의 Lambda 함수에서 멤버 계정으로 RunCommand 수행하기

SSM 자동화 기능을 통해 AWS Organizaitons 서비스를 통해 구성된 OU별로 Lambda 함수 구현 없이 RunCommand 수행이 가능합니다.

다만 각 인스턴스의 점검 결과를 S3의 Presigned URL을 통해 S3로 업로드 하는 방식을 채택하여, 각 인스턴스별로 각기 다른 URL 파라미터를 주입해야 한다는 점에서 Lambda 함수를 통해서 RunCommand를 수행하게 되었습니다.

모든 EC2 인스턴스 대상으로 앞서 작성한 SSM Document를 전달하여 명령을 수행하거나, 인스턴스를 직접 선택하여 명령을 수행할 수 있도록 상황에 맞는 취약점 점검을 수행하기 위해 Lambda 함수를 역할에 맞게 배치하여 RunCommand 수행 과정을 자동화하였습니다. 이 과정에서 다른 계정에서 RunCommand를 실행할 수 있는 권한을 부여받기 위해 AWS Security Token Service의 AssumeRole API를 사용하여 수행하였습니다.

먼저 모든 멤버 계정 내 테라폼을 통해 필요한 권한을 가진 IAM 역할을 작성 후 배포했습니다. 해당 IAM 역할은 신뢰관계 내 보안 주체에 Lambda 함수에 부착된 IAM 역할의 ARN을 입력해두어, Lambda 함수에서 해당 권한을 정상적으로 획득할 수 있도록 구현했습니다.

아래는 Lambda 함수의 코드를 통해 수행되는 로직을 개념화한 다이어그램입니다.

1. 앞서 작업 대상 계정에 생성했던 IAM 역할에 대한 AssumeRole 요청을 수행하여 자격증명을 획득합니다.
2. SSM 서비스의 DescribeInstancesInformation API를 호출하여 InstanceID와 SSM Document Parameter 에 활용될 Instance Name, Instance IP를 획득합니다. 진단이 필요한 OS 타입을 지정하거나, SSM 서비스와의 연동 상태가 정상인 인스턴스를 확인하는 등 필터 옵션을 통해 특정 조건을 만족하는 인스턴스를 선별할 수 있습니다.
3. SSM 서비스의 SendCommand API를 통해 2번 과정에서 획득한 InstanceID 리스트 대상으로 미리 작성한 SSM 문서를 실행합니다.
   1. SSM Run Command 내 태그, 리소스 그룹등을 바탕으로 명령을 대규모로 실행하는 기능을 지원하고 있고, 이를 통해 동시 실행 가능한 범위 지정, 오류 발생 시 중단 기능을 사용할 수 있습니다. 위 다이어그램에선 인스턴스마다 각기 다른 파라미터를 주입하기 위해 Lambda 함수를 통해 반복 처리하도록 구성했습니다.
   2. 인스턴스가 다수인 경우, 쓰로틀링을 방지하기 위해 하기 예시와 같은 요청 속도를 제한하는 옵션 사용을 고려해볼 수 있습니다.

      func GetDefaultClient(ctx context.Context, accountID string) (*SSMClient, error) {
      	cfg, err := config.LoadDefaultConfig(ctx, config.WithRegion(TargetRegion), config.WithRetryer(func() aws.Retryer {
      		return retry.NewStandard(func(o *retry.StandardOptions) {
      			o.RateLimiter = ratelimit.NewTokenRateLimit(20)
      			o.RetryCost = 1
      			o.RetryTimeoutCost = 3
      			o.NoRetryIncrement = 10
      		})
      	}))
      
      	if err != nil {
      		return nil, err
      	}
      
      	stsClient := sts.NewFromConfig(cfg)
      	creds := stscreds.NewAssumeRoleProvider(stsClient, fmt.Sprintf(AssumeRoleARN, accountID, AssumeRoleName))
      	cfg.Credentials = aws.NewCredentialsCache(creds)
      
      	ssmClient := ssm.NewFromConfig(cfg)
      
      	return &SSMClient{ssmClient}, nil
      }
      

SendCommand API 호출 시 완료/실패 수를 저장한 뒤, 모든 로직이 마무리되고 결과 보고서를 메신저로 전달하도록 구성했습니다. 빗썸에서는 Slack에서 제공하는 API를 활용해 아래와 같은 템플릿으로 결과가 전달되도록 처리했습니다.

IAM 역할 및 정책 작성 후 배포하기

Lambda 함수에서 사용하고 있는 IAM 역할 ARN 값을 신뢰관계의 principal 부분에 명시함으로써 Lambda 함수에서 해당 권한을 정상적으로 획득할 수 있도록 구현했습니다.

• IAM 정책

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "ssm:SendCommand",
          "ssm:ListCommandInvocations",
          "ssm:ListCommands",
          "ssm:DescribeInstanceInformation"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Allow",
        "Action": "ec2:DescribeInstances",
        "Resource": "*"
      }
    ]
  }

• IAM 신뢰 관계

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "AWS": [
            "arn:aws:iam::123456789012:role/service-role/runcommand-lambda-single-role-******",
            "arn:aws:iam::123456789012:role/service-role/run-command-lambda-role-******"
          ]
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }

3. S3 Presigned GET URL을 통한 EC2 내 점검 스크립트 전달

인스턴스의 보안설정 오류(misconfiguration) 취약점을 확인할 수 있는 쉘 스크립트를 인스턴스에 전달하기 위해, 먼저 중앙 S3 버킷에 점검 스크립트를 업로드 하였습니다.

이후 Lambda 함수에서 일정 시간 동안만 접근할 수 있는 Presigned URL을 생성하여 SSM 문서에 정의한 downloadURL 파라미터에 해당 URL 주소를 전달함으로써 인스턴스에서 S3 객체에 대한 접근 권한이 없어도, 스크립트를 다운로드받을 수 있게 구성했습니다.

S3 버킷에 업로드하는 방안은 다음과 같이 여러가지가 있으나 문서 수정 없이도 점검 스크립트를 유연하게 변경할 수 있어야 하고, EC2의 인스턴스 프로필 내 명시적인 정책 추가 없이 취약점 점검을 해야하는 요구사항을 충족시키기 위해 Presigned URL을 활용하여 업로드하는 방안을 선택했습니다.

1. Command 문서에 스크립트를 직접 추가하는 방법
2. EC2 의 인스턴스 프로필에 특정 S3 버킷만 접근 가능하도록 정책을 추가하고, 해당 버킷의 버킷 정책으로 접근 제어하는 방법
3. S3의 스크립트를 다운로드할 수 있는 Presigned URL을 통하여 일정 시간만 접근할 수 URL 을 생성하여 전달하는 방법

PresignedURL 생성 코드

다음은 Lambda 함수에 부여된 IAM 역할을 통해 특정 버킷 내 객체를 다운로드 할 수 있는 Presigned URL을 생성하는 예제 코드입니다. 지정한 time.Duration(분) 시간만큼 유효한 URL을 생성해 인스턴스에 전달함으로써, 인스턴스에 s3 관련 정책을 부여하지 않고, 특정 S3 버킷에 업로드되어 있는 객체의 다운로드가 가능합니다.

• Presigned URL 생성 코드

  func CreateURLToGet(ctx context.Context, key string, time_expire int64) (string, error) {
  	cfg, err := config.LoadDefaultConfig(ctx, config.WithRegion(TargetRegion))
  	if err != nil {
  		return "", err
  	}
  	s3Client := s3.NewFromConfig(cfg)
  	PresignClient := s3.NewPresignClient(s3Client)
  
  	resp, err := PresignClient.PresignGetObject(ctx, &s3.GetObjectInput{
  		Bucket: aws.String(BucketName),
  		Key:    aws.String(key),
  	}, func(o *s3.PresignOptions) {
  		o.Expires = time.Minute * time.Duration(time_expire)
  	})
  
  	if err != nil {
  		return "", err
  	}
  
  	return resp.URL, nil
  }
  

• Presigned URL을 활용한 SSM 문서 단계

  {
    "action": "aws:runShellScript",
    "name": "Download_CCE_Script",
    "precondition": {
      "StringEquals": [
        "platformType",
        "Linux"
      ]
    },
    "maxAttempts": 3,
    "inputs": {
      "workingDirectory": "{{ workingDirectory }}",
      "runCommand": [
        "#!/bin/bash",
        "#################################################",
        "# Get CCE Script",
        "#################################################",
        "curl -o script.tar '{{ scriptUrl }}'",
        "curl -sS -w \"%{http_code}\" -o {{ workingDirectory }}/script.tar '{{ scriptUrl }}'",
        "tar -xf script.tar"
      ]
    }
  }

4. S3 Presigned PUT URL을 통한 점검결과 수집

취약점 점검 결과는 tar 형태로 서버 내 생성됩니다. 생성된 결과파일을 S3 버킷으로 업로드하기 위해 특정 Key로 객체를 업로드할 수 있는 권한이 부여된 Presigned URL을 생성했고, SSM 문서에 정의한 uploadURL 파라미터로 해당 URL 주소를 전달함으로써 인스턴스에서 S3 객체에 대한 접근 권한이 명시적으로 없어도, 결과 파일을 업로드할 수 있도록 구성했습니다.

계정 별로 Prefix를 지정하여 결과를 수집

한 계정의 전체 인스턴스 점검 결과가 수집된 모습

PresignedURL 생성 코드

다음은 Lambda 함수에 부여된 IAM 역할을 통해 특정 버킷 내 Key로 파일을 업로드할 수 있는 Presigned URL을 생성하는 예제 코드입니다. 지정한 time.Duration(분) 시간만큼 유효한 URL을 생성해 인스턴스 단에 전달함으로 써, 인스턴스 내 s3 관련 Policy를 부여하지 않고, 특정 S3로 파일 업로드가 가능합니다. 이 경우, Lambda에 부여된 Role의 Policy를 따르므로, 생성한 URL에 IP ACL과 같은 보안 정책 적용이 가능합니다.

• Presigned URL 생성 코드

  func CreateURLToPut(ctx context.Context, key string, time_expire int64) (string, error) {
  	cfg, err := config.LoadDefaultConfig(ctx, config.WithRegion(TargetRegion))
  	if err != nil {
  		return "", err
  	}
  	s3Client := s3.NewFromConfig(cfg)
  	PresignClient := s3.NewPresignClient(s3Client)
  
  	resp, err := PresignClient.PresignPutObject(ctx, &s3.PutObjectInput{
  		Bucket: aws.String(BucketName),
  		Key:    aws.String(fmt.Sprintf("%s/%s/%s", "Result", Target, key)),
  	}, func(o *s3.PresignOptions) {
  		o.Expires = time.Minute * time.Duration(time_expire)
  	})
  
  	if err != nil {
  		return "", err
  	}
  
  	return resp.URL, nil
  }
  

• PresignedURL을 활용한 SSM 문서 단계

  {
    "action": "aws:runShellScript",
    "name": "Upload_result",
    "maxAttempts": 3,
    "precondition": {
      "StringEquals": [
        "platformType",
        "Linux"
      ]
    },
    "inputs": {
      "workingDirectory": "{{ workingDirectory }}",
      "runCommand": [
        "#!/bin/bash",
        "#################################################",
        "# Upload Result",
        "#################################################",
        "hostname=$(hostname)",
        "result=\"${hostname}.tar\"",
        "curl -sS -w \"%{http_code}\" -X PUT -T \"$result\" \"{{ uploadUrl }}\""
      ]
    }
  }

5. 수집된 결과 파일 분석 및 시각화

앞서 기술한 과정으로 취약점 점검 결과 파일은 중앙 S3 버킷에 저장됩니다. 위 아키텍처를 통해 인스턴스 취약점 점검 결과는 정기적으로 수집되어 최신 보안 상태를 가지고 있습니다. 이를 분석하여 시각화하는 아키텍처를 구성하였습니다.

AWS에서는 S3버킷에 저장된 데이터를 분석할 수 있는 다양한 도구들이 제공되지만, 이 아키텍처에서는 분석 애플리케이션의 특성 상 별도의 분석 서버를 운영하는 방식을 채택했습니다. 이유는 분석 작업이 데이터 처리량이 많고, 특정 라이브러리나 환경이 요구되는 경우가 있기 때문입니다. 이러한 요구 사항을 충족하기 위해 S3에서 분석 서버로 S3 sync 명령을 통해 결과 파일을 일괄적으로 전달하여 분석 작업을 수행합니다.

aws s3 sync s3://<버킷명>/results/ /path/to/local/analysis/

분석 서버에선 전달받은 파일 기준으로 취약점 내용을 파싱하고, 필요한 정보를 추출합니다. 분석 결과는 SIEM 솔루션에서 쉽게 처리할 수 있도록 구조화시키는 목적으로 JSON 형식으로 반환합니다.

분석이 완료된 JSON 파일들은 다시 S3 버킷으로 업로드합니다.

aws s3 sync s3://<버킷명>/results/ /path/to/local/analysis/

SIEM 솔루션에선 S3 버킷 내 특정 Prefix에 저장된 JSON 파일을 모니터링하며, 새로운 파일이 업로드되면 이를 자동으로 수집합니다. 수집된 데이터는 시각화 도구를 통해 분석되고, 검색 쿼리를 통해 필요한 정보를 손쉽게 조회할 수 있습니다. 또한 위 과정으로 시각화된 결과물을 관련 부서들과 함께 확인할 수 있는 환경을 만듦으로써, 효율적인 취약점 관리 및 개선방안 도출이 가능해졌습니다.

결론

AWS Systems Manager를 활용한 자동화된 보안 취약점 점검 솔루션은 복잡한 환경에서도 뛰어난 확장성과 신뢰성을 제공합니다.

유연하게 확장되는 대규모 EC2 인스턴스의 보안 취약점 점검을 AWS Systems Manager 서비스를 활용하여 운영중인 서비스의 영향도 없이 자동화 하였습니다. 이로 인해 점검 시간이 수 일 걸리는 서버 취약점 진단이 최대 1일 이내로 단축되고 놓치는 EC2 없이 보안 수준을 항상 동일 수준으로 유지할 수 있는 환경이 되었습니다. 또한, 불필요한 자원을 생성하지 않고 AWS Contol Tower에서 기본으로 배포되어지는 자원을 활용함으로써 해당 솔루션을 빠르게 구성할 수 있었고, 기존 투입되던 인력 자원이 최소화함은 물론 보안 강화와 컴플라이언스 준수에 크게 기여했습니다.

앞으로 EC2 인스턴스 뿐 아니라, RDS 서비스에 대해서도 자동화된 취약점 점검을 할 수 있도록 검토중이며, 더 나아가 빗썸만의 클라우드 기술력을 활용하여 클라우드 대용량 Native Service Log와 Security Native Service의 Finding Data를 활용하여 CSPM, CIEM, CWPP를 아우를 수 있는 통합 클라우드 보안 플랫폼을 설계, 자체 구축할 예정입니다.

AWS의 관점에서, 빗썸에 적용한 자동화된 보안 진단 시스템은 클라우드 자산의 유연성을 최대한 활용하면서도 보안과 컴플라이언스를 강화할 수 있는 방법을 제시합니다. 클라우드 환경의 확장성과 복잡성이 증가하는 현재와 같은 상황에서, AWS Systems Manager는 보안 취약점을 자동으로 관리할 수 있는 뛰어난 도구로서 기업들이 신뢰할 수 있는 보안 기반을 제공할 것입니다. 앞으로도 AWS는 고객이 복잡한 클라우드 환경에서 쉽게 보안을 유지하고 컴플라이언스를 준수할 수 있도록 다양한 기능과 솔루션을 지속적으로 발전시켜 나갈 것입니다.