grep

DevOps

안전한 결제 정보 전송을 위한 DX구축기

Hannibal여기어때

2024년 12월 3일

원문에서 보기 ↗

안녕하세요. 여기어때컴퍼니 SRE팀에서 클라우드 엔지니어링 업무를 하고 있는 한니발입니다.

일반적으로 기업이 상품을 판매한다는 것은 판매된 상품에 대한 결제 정보와 데이터가 카드사로 전달된다는 것을 의미합니다. 여기어때의 경우에도 숙박, 레저, 티켓 등 다양한 상품이 있으며, 고객이 이러한 상품을 결제할 때 결제 정보를 카드사로 전송해야 합니다. 결제 과정에서 민감한 데이터가 포함되기 때문에 네트워크 안정성과 보안성을 확보하는 것이 매우 중요했습니다.

이러한 요구사항을 충족하기 위해, 안정적인 네트워크 연결을 제공하는 AWS Direct Connect(DX)를 도입하여 아키텍처를 설계하고 구축하게 되었습니다.

그렇다면 왜 DX가 가장 안전하고 안정적인 방법일까요?

카드사와 통신할 수 있는 방법은 여러 가지가 있지만, 대표적으로 API 방식, VPN 터널링 방식, 그리고 Router 장비를 활용한 전용선 방식이 있습니다.

세 가지 방식의 장단점을 분석해 본 결과는 위 표와 같습니다.

카드사와의 통신에 포함되는 데이터는 고객이 민감하게 생각하는 결제 정보입니다. 그래서 우리는 다른 방식에 비해 안정성이 높은 AWS Direct Connect(DX)를 선택하게 되었습니다. DX는 인터넷을 거치지 않고 AWS와 온프레미스(IDC Router)를 전용 네트워크로 직접 연결함으로써 안정적으로 데이터를 전송할 수 있고, 지연시간을 줄일 수 있습니다 또한, AWS Virtual Gateway(VGW)를 통해 패킷 암호화를 추가로 적용하여 데이터가 유출되더라도 내용을 확인할 수 없도록 보안을 강화했습니다. 이로써 안정성과 보안성을 모두 충족하는 네트워크 환경을 성공적으로 구축할 수 있었습니다.

먼저 도입 전 요구사항을 말씀드리면 아래와 같습니다.

1. 사전 요구조건

카드사 요구사항

여기어때컴퍼니 요구사항

카드사측과 초도 미팅에서는 요구사항을 충족할 수 있는 두 가지 방안을 논의했습니다.

  1. 기존 네트워크 장비를 활용
  2. 클라우드 네이티브 방식을 활용

논의 끝에, 유지보수가 더 간편하고 운영 효율성이 높은 AWS VGW(Virtual Private Gateway)를 활용하는 클라우드 네이티브 방안을 선택하게 되었습니다. 이 구성은 트래픽이 적은 환경에서도 안정적으로 네트워크 연결을 제공합니다. 또한, 장비 관리 부담을 줄여 운영 효율성을 높이는 데 기여했습니다.

이러한 장점을 바탕으로 논의 끝에 최종적으로 아래와 같은 아키텍처를 도출했습니다. 이후 논의를 거쳐 아래와 같은 초기버전 아키텍처를 도출하게 되었습니다.

2. 아키텍처 구성

초기 아키텍처

2.1 초기버전 아키텍처 설명

Private 통신이 필요했으나, 카드사 IP 대역이 RFC 규약상 Public 대역으로 인식되었습니다. 이로 인해 AWS에서도 TGW에 Public IP가 할당되는 이슈가 발생했습니다.

주의 해야 할 점은 DX사업자마다 Private 라우팅 설정이 가능한 업체도 있고 불가능한 업체도 있다는 점입니다. 해당 이슈로 아키텍처를 수정하기 위해 Public통신으로 VPN망을 구성할 수 있는지 또 해당 구성 시에 보안 이슈가 없는지 조사를 하였습니다.

AWS에 문의한 결과, AWS Public IP는 Public 구간에 포함되므로 DDoS나 Brute force와 같은 공격을 받을 가능성이 있지만, AWS 자체 방화벽에서 차단하고 있다는 답변을 받았습니다. 또한, VPN 통신의 암호화 키는 공개되지 않아 보안에 문제가 없다고도 했습니다.

이 경우 참고하기에 적절한 레퍼런스를 확인하여 아키텍처를 수정하게 되었습니다. 이 내용을 토대로 나온 결과물이 두 번째로 설명드릴 ‘개선된 아키텍처’이며, 아래와 같습니다

개선된 아키텍처

2.2 개선된 아키텍처 설명

가장 큰 차이점은 TGW->VGW로 변경된 점입니다. VPN구간은 Public IP를 통해 통신하도록 구간입니다. 그리고 이 DX에 Public VIF(Virtual Interface)의 경우 AWS에 요청하여 IP 대역을 할당 받아야 합니다. Public IP를 할당받아 VIF를 생성 하였습니다.

여기까진 수월하게 진행이 되었지만 카드사<-> DX 구간에 문제가 발생하였습니다. 원인은 Public VIF로 온프레미스를 연결할 경우 BGP broadcast에 대해 AWS에서 자체 방화벽에 IP를 Whitelist로 등록해야 했는데, 이를 하지 않았던 것 입니다. LOA(letter of Authorization)을 작성하고, AWS 측에 요청을 해야 Whitelist 처리가 가능 합니다.

아래는 작성 예시 입니다.

LETTER OF AUTHORIZATION (LOA)
[날짜]
To whom it may concern,
This letter serves as authorization for [ 회사명 ] with Account Number: [ AWS account Number>
to use the BGP Autonomous System Number (ASN) or advertise the following IP address prefixes over the Public Virtual Interface [연결할 DX VIF]:
[ BGP ASN ] - Example of BGP ASN that needs to be approved
[온프레미스 IP] IPv4 address/CIDR prefixes that need to be approved
As a representative of [회사 주체], the owner of BGP ASN and these subnets, I hereby declare that I'm authorized to represent and sign for this LOA.
From,
[서명]
[이름]
[직급]
[IP 소유자 회사 이름]
[IP 소유자 전화 번호]
[IP 소유자 이메일 ID]

해당 처리가 완료되면 아래와 같이 콘솔 상태 확인과 트래픽 모니터링이 가능합니다.

DX 연동 확인 콘솔 화면

구축이 끝났으니 운영하는 데 중요한 요소를 생각해야 합니다. 그것은 바로 모니터링입니다.

3. DX 모니터링

3.1 DX (Connection State)

모니터링 부분은 워낙 다양한 솔루션과 환경이 사용되기 때문에, AWS에서 제공하는 기본적으로 제공 하는 매트릭 기준으로 간단히 설명 드리겠습니다. 먼저 AWS ↔︎ DX 서비스 사에 문제가 발생 할 경우는 ConnectionState 관련 매트릭을 참조 하시면 됩니다.

0 → 연결 문제 발생

1 → 연결 정상

DX connection status

3.2 DX (Traffic In/Out)

AWS ↔︎ DX 서비스 사 간에 트래픽 모니터링 하시게 되면 VirtualInterfaceBpsIn/Egress, VirtualInterfacePpsIn/Egress 그래프를 유의하여 보시면 됩니다.

DX Traffic In/Out

4. DX구축 타임라인

마지막으로 이 글에서 설명드린 전체 작업에 대한 순서를 간단히 정리하겠습니다. 다만 구체적인 소요시간, 일정은 공유가 어려우니 양해 부탁 드립니다

이번 프로젝트를 통해 클라우드와 온프레미스 간 연결은 단순히 기술만으로 이루어지는 것이 아니라, 행정적 절차와 다양한 협업이 필요하다는 점을 깨달았습니다. AWS 서비스 선택 과정에서 고려해야 할 점이 특히 많았고, 각각의 옵션이 가진 장점과 제한 사항을 신중히 검토해야 했습니다. 콘솔에서 간단히 보이는 작업도 실제로는 많은 과정과 조율이 필요하다는 것을 배웠습니다.

이번 프로젝트를 통해 팀원들과 협력하며 위에서 말씀드린 대로 많은 것을 느낄 수 있었고, 이러한 과정을 함께 극복해 나간 점에서 또한 큰 의미를 부여하고 싶습니다. 이 글이 비슷한 프로젝트를 준비하시는 분들께 조금이나마 도움이 되었으면 좋겠습니다.

함께해 주신 모든 분들께 감사드립니다.