AWS Lambda with VPC
회사에 인터넷 액세스가 없고 개인 DNS 호스트네임 옵션이 활성화된 VPC가 있습니다. 이 VPC 내부에서 Amazon Aurora 데이터베이스가 실행 중입니다. 보안 엔지니어는 AWS Secrets Manager를 사용하여 Aurora 데이터베이스의 자격 증명을 자동으로 회전하고자 합니다. 보안 엔지니어는 Secrets Manager 기본 AWS Lambda 회전 함수를 Aurora 데이터베이스가 사용하는 동일한 VPC 내에서 실행하도록 구성합니다. 보안 엔지니어가 Lambda 함수가 Secrets Manager와 통신할 수 있게 하는 가장 안전한 방법은 무엇일까요?
이 문제를 실제로 구성하고 해결하기 위해서 다음과 같은 서비스를 사용할 예정입니다 :
AWS Lambda: 서버리스 컴퓨트. 깊이 들어가지 않겠습니다.
Amazon RDS: 관리되는 관계형 데이터베이스 서비스. 더 깊게 알고 싶다면, AWS RDS와 Aurora를 사용한 관리형 관계형 데이터베이스를 읽어보세요.
AWS Secrets Manager: 암호화된 문자열(예: 비밀번호)을 저장하고 안전하게 접근할 수 있는 서비스입니다. AWS Secret Manager
Amazon VPC: RDS 인스턴스가 배치되는 가상 네트워크입니다.
단계 1: “람다를 VPC 안에 넣기”
먼저, 우리는 “람다를 VPC 안에 넣을” 것입니다. 이를 위해 람다 서비스로 이동하여 람다를 선택하고, 구성(Configuration)을 클릭한 후 왼쪽에 있는 VPC를 클릭하고 편집(Edit)을 클릭합니다. 여러분의 VPC를 선택하고, 몇 개의 서브넷과 보안 그룹(Security Group)을 선택한 다음 저장(Save)을 클릭합니다(보안 그룹에 대해서는 다시 돌아오겠습니다).
우리의 람다 함수는 여전히 AWS의 람다용 공유 서버에서 실행되지만, 이제 그 VPC의 주소 공간 안에 IP 주소를 갖게 되었습니다. 이것은 이제 우리의 람다 함수가 공공 인터넷 대신 VPC를 통해 패킷을 보내 RDS 인스턴스에 접근할 수 있다는 것을 의미합니다(더 빠르고 안전합니다).
이제 우리는 람다에 대한 인터넷 접근을 막았습니다! “VPC 안에 있지 않은” 람다들이 사실은 인터넷 접근이 가능한 “비밀” VPC 안에 존재한다는 것이 밝혀졌고, 우리가 람다를 우리 VPC로 옮기면서 그 접근을 막았습니다. 우리의 람다가 인터넷에 접근해야 한다면, 이 문제를 해결하는 방법은 다음과 같습니다. 만약 우리의 람다가 접근해야 하는 것이 다른 AWS 서비스들뿐이라면, 인터넷 접근에 신경 쓰지 말고 계속 읽으세요.
단계 2: VPC 인터페이스 엔드포인트 추가
우리는 람다 함수의 시크릿 매니저 접근도 막았고, 이것은 확실히 중요한 문제입니다. 이를 해결하기 위해, 우리는 VPC 인터페이스 엔드포인트를 추가할 것입니다. 이는 AWS 서비스에 우리 VPC 안에 사설 IP 주소를 주는 것과 같아, 우리가 그 주소로 서비스를 호출할 수 있게 합니다(인터넷 접근을 막았기 때문에 공용 주소는 접근할 수 없습니다).
VPC 콘솔로 이동하여 “엔드포인트(Endpoints)”를 선택하고 “엔드포인트 생성(Create Endpoint)”을 클릭합니다. “com.amazonaws.{region}.secretsmanager” 서비스 이름을 선택하고, 여러분의 VPC, 람다 함수에 선택한 서브넷들, 보안 그룹을 선택하고 저장(Save)을 클릭합니다.
단계 3: 보안 그룹 생성
이제 모든 것이 같은 VPC 내에 있으므로, 다른 구성 요소로 트래픽이 도달하게 하면서 다른 모든 트래픽은 차단해야 합니다. 보안 그룹은 이를 가능하게 하는 정말 멋진 방화벽입니다.
먼저, SecretsManagerSG라는 보안 그룹을 생성하고 VPC 엔드포인트와 연결하세요. LambdaSG라는 다른 보안 그룹을 생성하여 람다 함수와 연결하고, DatabaseSG라는 또 다른 보안 그룹을 생성하여 RDS 인스턴스와 연결하세요.
다음으로, DatabaseSG를 편집하여 LambdaSG에서 오는 데이터베이스 포트(5432, 3306 등)로의 인바운드 트래픽을 허용하세요.
마지막으로, SecretsManagerSG를 편집하여 LambdaSG에서 오는 모든 프로토콜과 포트에 대한 인바운드 트래픽을 허용하세요.
단계 4: 람다 함수에 IAM 권한 부여하기 네트워킹 부분은 이것으로 끝입니다. 이제 IAM 역할을 사용하여 적절한 권한을 구성해야 합니다. IAM 서비스로 이동하여 “역할(Roles)”을 클릭한 다음 “역할 생성(Create Role)”을 클릭하세요. 신뢰할 수 있는 엔터티로 “AWS 서비스”를 선택하고, 이 역할을 사용할 서비스로 “Lambda”를 선택하세요. “다음: 권한(Next: Permissions)”을 클릭하고, “정책 생성(Create policy)”을 클릭한 다음 다음 정책을 사용하세요.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"{database-arn}"
]
},
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:secretsmanager:{region}:{account_id}:secret:{secret name}"
]
}
]
}
AWS 람다 함수를 VPC에서 구성하는 이유
정말로 이 모든 것이 필요할까요? 네, 필요합니다. 그 이유는 다음과 같습니다:
람다를 VPC 안에 배치하기: 성능과 보안을 위해서입니다. 람다를 VPC 안에 배치하지 않으면, 공공 인터넷을 통해서만 RDS 인스턴스에 연결할 수 있습니다. 한편으로는, 이것은 더 많은 네트워크 점프를 의미하며, 이는 속도를 느리게 합니다. 다른 한편으로, 데이터베이스를 인터넷에 개방해야 합니다(네트워킹 측면에서, 여전히 비밀번호는 있지만), 이는 보안이 떨어집니다. 비밀번호가 있긴 하지만, 대부분의 경우에 충분할 수 있지만, 위험을 감수하고 싶지 않습니다. 여러 방어층(이 경우 네트워크와 인증)을 추가하는 것은 깊이 있는 방어라는 전략입니다.
VPC 엔드포인트 추가하기: 이것은 꽤 비슷하지만, 반대 방향입니다. 시크릿 매니저는 공공 서비스이므로, AWS 공유 VPC(예를 들어, EC2나 RDS 인스턴스처럼 당신이 소유한 VPC에 있는 것과는 반대로)에 위치합니다. 공공 서비스에 연결하려면, 다른 공공 서비스(예: VPC에 있지 않은 함수인 람다)를 통해, 인터넷을 통해, 또는 당신의 VPC 내 VPC 엔드포인트를 통해 할 수 있습니다. 첫 번째 옵션은 더 이상 가능하지 않습니다(람다 함수는 당신의 VPC나 공유 VPC 중 하나에만 있을 수 있으며, 둘 다에 있을 수는 없습니다). 당신의 서브넷에서 NAT 게이트웨이로 경로를 추가하여 람다 함수가 인터넷에 도달할 수 있게 할 수 있습니다(사실, 함수가 인터넷 접근이 필요하다면 이것을 해야 합니다), 하지만 트래픽은 인터넷을 통해 가게 됩니다(성능과 보안에 좋지 않습니다). 대신, 시크릿 매니저에 당신의 VPC 내 사설 IP 주소를 줄 수 있습니다(VPC 엔드포인트가 본질적으로 하는 일), 그리고 연결이 당신의 VPC와 AWS의 내부 네트워크를 통해 이루어지게 할 수 있습니다.
보안 그룹: 이것은 본질적으로 깊이 있는 방어에 관한 것입니다. RDS 보안 그룹의 인바운드 트래픽을 제한함으로써, 당신의 람다 함수 외의 누구도 데이터베이스에 연결할 수 없도록 방지합니다. 이것은 인터넷의 악의적인 해커들뿐만 아니라, 당신의 VPC 내의 다른 자원들(예: EC2 인스턴스)도 포함합니다. 이 뒤에 있는 논리는, 여러 자원들(예: 여러 람다나 인스턴스들)이 있다면, 그 중 하나가 손상될 수 있고, 그 자원에 접근할 수 있는 악의적인 해커가 할 수 있는 것을 제한하고 싶다는 것입니다.
VPC 내 AWS 람다 함수를 위한 모범 사례
운영 우수성
VPC 플로우 로그 사용하기: VPC 내 네트워크 트래픽을 모니터링하고 잠재적인 보안 문제를 식별하기 위해 VPC 플로우 로그를 활성화하세요.
서비스 할당량 모니터링: 특히, VPC 내의 람다가 서브넷당 하나의 ENI(탄력적 네트워크 인터페이스)를 사용하기 때문에 ENI 할당량을 주시해야 합니다. 이 경우에는 하나의 서비스에만 접근하기 때문에 하나의 VPC 엔드포인트만 생성하지만, 여러 개를 생성할 경우에는 이에 대한 할당량도 낮습니다.
단일 책임 서비스: 단순함을 위해 단 하나의 람다 함수만으로 이 시스템을 구축하고 있으며, 시스템이 정확히 한 가지 일만 한다고 가정합니다. 실제로는 시스템이 여러 가지 일을 하게 되며, 이러한 작업은 여러 서비스(그리고 여러 람다 함수)에 걸쳐 분할되어야 합니다. 이 이슈에서 서비스 설계에 깊이 들어가고 싶지 않습니다. 왜냐하면 그렇게 하면 VPC 내 람다의 기술적 측면에서 초점이 벗어나기 때문입니다. 하지만 실제로 이를 구현한다면, 모든 코드를 단일 람다에 넣지 마세요.