인프라 보안
인프라 보안
네트워크 보안
클라우드 환경뿐 아니라 기존 IT 환경에서 네트워크 보안은 전체 보안의 핵심 요소로 간주됩니다.
이는 네트워크가 전체 호스트에 대한 접근을 제어하며, 불특정 다수에게 시스템과 데이터에 대한 접근을 허용하는 유일한 기술적 수단이기 때문입니다.
네트워크 제어를 구성할 때는 공격자를 차단하고 합법적 사용자가 정상적으로 사용할 수 있도록, 정밀한 접근 정책을 수립해야 합니다.
더욱이 클라우드는 사용자 네트워크 외부, 즉 인터넷상에 존재하기 때문에, 인터넷 연결을 전제로 구축되고 운영되어야 합니다.
또한 대부분의 최신 Application은 인터넷 연결을 기반으로 개발되므로, 인터넷 연결을 배제할 수 없습니다.
클라우드에서 네트워크 아키텍처를 구성하고 정책을 수립할 때는, 사용자가 구축하는 정보시스템의 각 구성 요소가 위치하는 네트워크 공간 및 접근 권한을 의도적으로 세분화하고 경계를 설정해야 합니다.
이러한 세분화 전략의 대상에는 네트워크, 사용자, 자원 접근 등이 포함됩니다.
네트워크 계층화
- 모든 서버는 기능별로 그룹화하고 각각 별도의 서브넷에 배치하며, 필요한 경우를 제외하고 모두 프라이빗 서브넷에 배치합니다.
- 인터넷에서 VPC에 접근 지점은 최소화하여 보안을 강화합니다.
- (중요 데이터가 저장되는) 저장소는 필요한 대상에게만 접근을 허용하도록 설정합니다.
개인정보나 기밀 데이터 등 보안 요구사항이 높은 영역은 외부 및 다른 구성 요소로부터 분리하고, 접근을 제한해야 합니다.
이를 통해 정보시스템의 일부에 무단 침입이 발생하더라도, 침해의 범위를 가능한 한 최소화할 수 있어야 합니다.
분리된 구성 요소는 동일한 보안 유형에 따라 그룹화하고, 경계를 설정하여 네트워크 접근을 제한합니다.
일반적으로는 웹, Application, 데이터베이스의 3계층 구조로 그룹화하며, 외부 네트워크가 접근하는 진입점은 별도의 경계로 구성합니다.
다음 그림은 이러한 3계층 웹서비스 아키텍처를 표현하고 있습니다.
워크로드 인터넷 격리 및 계층화
위 그림에서는 Web, Application, DB로 서브넷을 생성했습니다.
이 아키텍처에서는 웹 서비스를 위한 전체 서버에 Private IP만 연결해서(Public IP를 연결하지 않아서), 인터넷 연결 없이 프라이빗 통신만 가능하게 합니다.
각 서버는 Web Server, Application Server, DB Server로 그룹화하여 각각 독립된 서브넷에 배치합니다.
외부에서 접근할 수 있는 Bastion Server를 생성해서 서버 관리를 수행합니다.
관리자는 VPN을 통해 Bastion Server에 프라이빗 연결하고, 이를 경유해서 각 서버에서 관리 작업을 수행합니다.외부 공격 표면의 최소화
인터넷에 노출하는 서버를 최소화하기 위해 아키텍처에서는 Load Balancer만 인터넷에 개방했습니다.
사용자는 Load Balancer의 Public IP를 통해서만 서비스에 접근할 수 있습니다.저장소 접근 제어
데이터베이스는 접근이 필요한 Application에서만 접근할 수 있도록 합니다.
규정 준수 요건에 따라 필요한 경우, Application Server가 데이터베이스에 직접 접근하지 않고, 접근 제어 서버를 경유하도록 구성해야 할 수 있습니다.
예를 들어, 정보보호관리체계(ISMS) 규정은 이와 같은 데이터베이스 접근 제어 관리를 필수 조건으로 요구하고 있습니다.
Storage는 접근할 수 있는 대상을 White List로 관리하여, 접근 제어 목록(ACL)을 구성합니다.
접근 제어 목록을 관리하는 저장소는 File Storage, Object Storage, Container Registry입니다. (Storage는 아니지만 Kubernetes Cluster도 접근 제어 목록을 관리합니다.)
접근 제어 목록 대상에는 Public IP 주소, Account 내의 서버, VPC Endpoint 등이 포함됩니다.
네트워크 트래픽 제어
Samsung Cloud Platform 내외부로 전송되는 트래픽에 엄격한 제어 규칙을 적용하여 보안 침투를 차단합니다. 이를 위해 서비스의 각 구성 요소의 연결 요구사항을 분석하여 네트워크 구조를 설계하고, 그에 따른 트래픽 제어 정책을 수립합니다.
네트워크 통신 제어 정책은 서비스의 특성에 따라 달라질 수 있습니다. 서비스 요구사항 분석을 통해 네트워크 흐름을 파악하고, 이에 따라 제어 정책의 기준을 정합니다.
- VPC 내부의 모든 자원에 대해 네트워크 통신 제어 정책을 수립합니다.
- 세밀하게(Fine Grained) 구성된 통신 제어 정책을 통해 송수신 트래픽을 제어합니다.
- 구성 요소 간 필요한 포트로 트래픽을 제한하는 심층 방어를 구성해서 전체 트래픽 흐름의 보안을 강화합니다.
[네트워크 흐름 요구사항 분석]
서비스의 연결 요구사항을 분석할 때 다음의 분류에 따라 네트워크 흐름을 파악할 수 있습니다.
외부 인터넷에서 접근 가능성
퍼블릭 서브넷: Public IP가 연결된 Virtual Server가 배포된 서브넷. 임의적 분류로서 이 서브넷의 Virtual Server는 인터넷과의 트래픽 관리를 수행합니다.
프라이빗 서브넷: Public IP를 연결하지 않은 Virtual Server가 배포된 서브넷. 임의적 분류로서 이 서브넷의 Virtual Server는 인터넷과 격리합니다.트래픽 방향
출발지 IP 주소, 목적지 IP 주소, 포트를 기준으로 트래픽 방향에 대한 정보를 구성합니다.
수신(Inbound): 해당 구성 요소로 들어오는 트래픽. 수신자 IP 주소는 트래픽을 제어하는 서버(집합)의 IP 주소(범위)가 됩니다.
송신(Outbound): 해당 구성 요소에서 밖으로 나가는 트래픽. 송신자 IP 주소는 트래픽을 제어하려는 서버(집합)의 IP 주소(범위)가 됩니다.영향 범위
North-South: VPC 외부와 내부 사이에 흐르는 트래픽으로, 주로 VPC 외부의 서비스 사용자와 워크로드 사이에 흐르는 트래픽입니다. 이 영역에는 Firewall, WAF, IPS 등의 보안 서비스(장비)가 배치되어 외부의 공격 및 침입을 차단하는 역할을 수행합니다.
East-West: VPC 내부의 구성 요소 사이에 흐르는 트래픽으로, 예를 들어 3계층 웹서비스에서 Web Server와 Application Server와 DB Server 간의 트래픽이 해당됩니다. 이 영역에는 서비스 성능 향상을 위한 장치(Load Balancer, Message Queue Service 등)이 배치되며, 각 서버 그룹간 통신 보안을 위해 분산 방화벽(Security Group)을 구성합니다. Samsung Cloud Platform의 Load Balancer는 Firewall과 연결하여 이 영역에서 통신을 제어할 수도 있습니다.
Samsung Cloud Platform에서 VPC 내부에서 트래픽을 제어할 때 이용할 수 있는 서비스는 Firewall과 Security Group입니다.
Firewall은 네트워크 경계(North-South)의 트래픽 제어에 사용되고, Security Group은 서버의 트래픽 제어(East-West)에 사용됩니다.
아래 그림은 Firewall과 Security Group을 이용해서 3계층 웹서비스의 트래픽 제어를 구현한 아키텍처를 보여줍니다.
North-South 트래픽의 제일 앞 단의 경계는 Internet Gateway이며, Firewall을 연결하여 트래픽을 제어합니다.
인터넷 상의 최종 사용자 또는 관리자의 통신은 Internet Gateway를 경유해서 VPC 내부로 진입합니다.
아래 표에서 Intertnet Gateway에 구성할 수 있는 Firewall 규칙을 참조할 수 있습니다.
인터넷 상의 최종 사용자는 Load Balancer에 HTTPS(443)로 접근하며, 아래 표 1-1과 같이 규칙을 지정합니다. 관리자는 Internet Gateway Firewall을 경유하여 Bastion Server에 접속하며, 1-2 규칙과 같이 이를 허용합니다.Bastion 서버에서는 관리자 단말의 IP 주소에서만 inbound 원격 접속을 허용하는 Security Group 규칙(2-1)을 추가하고, VPC 내의 서버에 연결된 모든 Security Group을 대상으로 하는 outbound 규칙(2-2)을 추가합니다. Web Server Security Group(4-3), Application Server Security Group(6-3)에서 이 Bastion 서버의 Security Group을 대상으로 추가하여 관리를 위한 서버 접근을 허용합니다.
Web Load Balancer에서는 인터넷의 사용자 요청을 수신하여, 후방의 Web Server에 분산 배포합니다.
Load Balancer의 Public NAT IP는 후방 서버를 대신하여 외부에 노출된 단일 접점으로, Web Server의 불필요한 인터넷 노출을 방지할 수 있습니다. Load Balancer에 Firewall 규칙을 구성하여 전송 트래픽의 네트워크 제어를 구성할 수 있습니다.
Load Balancer에서 수신 포트와 전송 포트를 다르게 구성하면, 네트워크 보호 측면에서 강화된 정책을 구성합니다.
예를 들어, 전방 트래픽을 HTTPS(443)로 수신(3-1)하고 Load Balancer에서 SSL Termination 수행한 뒤, 후방의 Application Server로 HTTP(80) 트래픽을 전송(3-2)하여 서비스 흐름의 포트를 변경할 수 있습니다.
이 경우, 수신 포트와 전송 포트를 다르게 지정하여 보안을 강화한다는 점 외에 후방 Web Server에서 SSL 암복호화 처리 부하를 줄이는 이점도 기대할 수 있습니다.
SSL 인증서는 별도로 Certificate Manager에 등록해서 관리합니다.Web Security Group은 전방 Load Balancer로부터 전송되는 HTTP(80) inbound 트래픽과 후방의 App Load Balancer로 송신되는 outbound 트래픽을 허용합니다.(4-1, 4-2)
App Load Balancer에서는 Web Server 주소를 출발지 주소, Service IP를 목적지 주소로 하고, inbound HTTP(80)을 허용하는 Firewall 규칙(5-1)을 구성합니다.
그리고, 전송 포트를 HTTP(8080)로 변경하여 Application Server로 향하는 Outbound 허용 규칙을 추가하여 또 한번 포트를 변경합니다.(5-2)Application Server Security Group에서는 App Load Balancer에서 수신하는 HTTP(8080) inbound 트래픽을 허용하는 규칙(6-1)과
DB 서버로 향하는 2866 포트의 outbound 트래픽을 허용하는 규칙(6-2)을 구성합니다.
이 때 2866 포트는 Samsung Cloud Platform Database 서비스가 기본적으로 사용하는 포트이며, 여기에서도 서비스 흐름의 포트를 변경하였습니다.Database는 앞의 Application Server Security Group을 대상으로 하는 inbound와 outbound 2866 포트 트래픽을 허용하고, DB 간의 통신을 허용하는 규칙이 구성되었습니다.(7-1, 7-2)
심층 방어는 보안 제어 계층을 겹겹이 생성하여 한 계층에서 방어에 실패하더라도 뒤에 위치한 다른 계층에서 공격자를 차단하는 개념입니다.
이렇게 방어 계층을 중첩으로 구성하려는 노력은 결국, 공격자가 어떠한 약점을 이용해 공격할지 파악할 수 없다는 것을 인정하고 방어에 실패할 수도 있다는 것을 인정하는 데서 출발합니다.
Firewall과 Security Group을 이용해서 각 계층별로 송수신 포트를 달리하여, 최종적으로 중요한 정보가 저장되어 있는 데이터베이스에 침입자가 도달하지 못하게 하는 것이 심층 방어의 목적입니다.
Samsung Cloud Platform의 Security Group은 특정 주소 범위(CIDR 등)뿐만 아니라 다른 Security Group을 허용 대상에 포함할 수 있습니다.
Security Group을 허용 대상으로 지정하면, 해당 Security Group에 연결된 모든 Virtual Server를 통신 허용 대상으로 지정할 수 있어서 만약 Auto-Scaling 등을 계층에 적용하는 경우, 주소 범위를 지정할 필요가 없는 이점이 있습니다.
다음 표는 위에서 설명한 규칙을 정리한 규칙 도표입니다.
| 번호 | 서비스 | 방향 | 출발지 주소/원격 | 목적지 주소/원격 | 프로토콜/포트 | 동작 |
|---|---|---|---|---|---|---|
| 1-1 | Internet Gateway Firewall | Inbound | 0.0.0.0/0 (Internet) | Web Load Balancer Service IP | HTTPS(443) | Allow |
| 1-2 | Internet Gateway Firewall | Inbound | Administrator’s Public IP | Bastion Server IP | RDP/SSH(3389/22) | Allow |
| 2-1 | Bastion Server Security Group | Inbound | Administrator’s Public IP | - | RDP/SSH(3389/22) | - |
| 2-2 | Bastion Server Security Group | Outbound | - | All Security Groups | RDP/SSH(3389/22) | - |
| 3-1 | Web Load Balancer Firewall | Inbound | 0.0.0.0/0 (Internet) | Web LB Service IP | HTTPS(443) | Allow |
| 3-2 | Web Load Balancer Firewall | Outbound | Web LB Service IP | Web VM IP(band) | HTTP(80) | Allow |
| 4-1 | Web Server Security Group | Inbound | Web LB Source NAT IP | - | HTTP(80) | - |
| 4-2 | Web Server Security Group | Outbound | - | App LB Service IP | HTTP(8080) | - |
| 4-3 | Web Server Security Group | Inbound | Bastion Server Security Group | - | RDP/SSH(3389/22) | - |
| 5-1 | App Load Balancer Firewall | Inbound | Web VM IP(band) | App LB Service IP | HTTP(80) | Allow |
| 5-2 | App Load Balancer Firewall | Outbound | App LB Service IP | Application VM IP(band) | HTTP(8080) | Allow |
| 6-1 | Application Server Security Group | Inbound | App LB Source NAT IP | - | HTTP(8080) | - |
| 6-2 | Application Server Security Group | Outbound | - | DB Security Group | 2866 | - |
| 6-3 | Application Server Security Group | Inbound | Bastion Server Security Group | - | RDP/SSH(3389/22) | - |
| 7-1 | DB Server Security Group | Inbound | Application Server Security Group, DB Security Group | - | 2866 | - |
| 7-2 | DB Server Security Group | Outbound | - | Application Server Security Group, DB Security Group | 2866 | - |
*이 구성에서는 Load Balancer 서버 그룹 멤버의 헬스 체크를 위한 규칙 설정은 포함되지 않았습니다.
네트워크 트래픽 필터링
Samsung Cloud Platform은 다양한 관리형 보안 서비스를 제공하고 있습니다.
사용자는 SR을 통하여 서비스를 신청하기만 하면 됩니다.
관리형 보안 서비스를 사용할 경우 장비에 대한 관리 업무 및 점검을 일임할 수 있으므로, 손쉽고 안전하게 워크로드를 보호할 수 있습니다.
- Secure Internet Gateway를 배포하고 관리형 보안 서비스를 신청합니다.
- 규정 준수 요구사항에 따른 적절한 보안 서비스를 사용합니다.
다음 그림은 관리형 보안서비스를 배치하여 보안을 강화한 3계층 웹서비스 아키텍처입니다.
다음 표는 Samsung Cloud Platform에서 제공하는 관리형 보안 서비스에 대한 기능과 방어할 수 있는 공격 유형에 대한 설명입니다.
| 보안 서비스 | 기능 | 관련 침해 유형 | |
|---|---|---|---|
| ❶ | WAF | 웹사이트 취약점을 노리는 HTTP, HTTPS 기반 보안 위협, 자동화 Bot 공격 방어 | Injection, XSS (Cross-Site Scripting), Web Scan 등 |
| ❷ | DDoS Protection | 대량 트래픽을 집중적으로 발생시켜 서비스 장애를 일으키는 DDoS공격 탐지/방어 | DDoS 공격 |
| ❸ | IPS | 악의적으로 추정되는 트래픽과 Application 조작 패턴을 감시 | 해킹 공격 탐지 |
| ❹ | Secured Firewall | 4 계층 트래픽 제어 | 무단 접근, IP 스캐닝 등 |
서버 보안
취약점 점검 및 조치
취약점은 공격자가 정보시스템의 보안 수준을 낮추기 위해 이용할 수 있는 시스템상의 약점을 의미합니다.
공격자는 취약점을 공격해 시스템의 권한을 획득하거나 중요 정보를 외부로 유출합니다.
서버 취약점 점검이란 가상 서버 운영체제의 보안 설정이 적절하게 적용되었는지를 확인하는 과정입니다.
Samsung Cloud Platform에서는 Linux 5종, Windows Server 운영체제를 제공하고 있습니다.
Application의 취약성은 완전히 제거할 수 없지만, 운영 체제, 파일 시스템 등의 보안을 강화하여 시스템 공격을 제한할 수 있습니다.
디렉토리 접근 강화와 프로세스 수준에서의 제한을 통해 공격을 방지하고, 파일 및 폴더 권한 설정, 필요한 접근만을 위한 별도 디렉토리 생성, 공통 접근 사용 지양, Application 재시작 자동화가 필요합니다.
최신 보안 패치 적용이 중요하며, OWASP의 안전한 코딩 모범 사례를 따르는 것이 권장됩니다.
필요시 도구를 통해 보안 패치 적용과 모니터링을 지원하며, 자동화 도구를 사용합니다.
다음은 주기적으로 점검해야 할 서버의 보안 관리 항목입니다.
| 관리 항목 | 관리 내용 |
|---|---|
| 운영체제 이름, 버전 | 운영체제 제공사의 기술 지원 기간(End Of Support) 관리 |
| 플랫폼, 미들웨어 SW 이름, 버전 | 웹서버, 데이터베이스 서버, 큐 등의 SW. 취약점 관리 목적 |
| 사용자 Application 코드 | 조직에서 운영하고 있는 모든 사용자 지정 Application 코드 |
| IP 주소, 서브넷 등 네트워크 정보 | 서버 IP 주소, VPC, 서브넷 등 네트워크 자산 정보 |
| 사용자, 인증 Key Pair | 운영체제에 접근이 허용된 사용자, Key Pair, 플랫폼/미들웨어/Application에 접근이 허용된 사용자 |
Container 환경에서는 Container Registry가 저장된 Container Image의 취약점을 점검할 수 있는 도구를 제공합니다.
Container Registry는 저장된 Container Image의 취약점을 점검할 수 있는 도구를 제공합니다.
프로비저닝 관리
Virtual Server나 Container를 프로비저닝할 때는 보안 취약점이 개선된 안전한 이미지를 사용하여 배포해야 합니다.
Virtual Server는 이미지를 통해 서버를 재배포할 수 있으므로, 최신 업데이트가 적용된 서버 이미지를 별도로 관리해야 합니다.
또한 이미지를 이용하여 서버를 가동할 때, 자동으로 최신 패치가 적용되도록 합니다.
컴퓨팅 환경에서 강화된 표준 이미지를 사용하여 프로비저닝을 하면, 보다 안전한 기본 환경을 제공할 수 있습니다.
이를 통해 불필요한 소프트웨어 패키지나 잠재적인 취약점이 포함되지 않은 상태에서 자원을 운영할 수 있으며, 외부로부터의 의도치 않은 침해 위험을 최소화할 수 있습니다.
특히 신뢰할 수 있는 레지스트리에서만 컨테이너 이미지와 Application 라이브러리와 같은 외부 종속성을 검색하고 서명을 확인하는 과정은 매우 중요합니다.
이러한 서명 확인 작업은 외부에서 취득한 소프트웨어가 변조되거나 악성 코드가 포함되지 않았는지 확인할 수 있는 효과적인 방법입니다.
또한 자체 프라이빗 레지스트리를 구축하고 신뢰할 수 있는 이미지와 라이브러리를 저장하는 것도 중요한 보안 절차 중 하나입니다.
프라이빗 레지스트리는 빌드 및 배포 프로세스에서 안전한 이미지를 참조할 수 있는 환경을 제공하며, 외부로부터의 의도치 않은 접근을 방지하는 방어막 역할을 합니다.
프라이빗 레지스트리에서는 정기적인 스캔과 업데이트를 통해 새로운 취약점에 대응할 수 있으며, 이를 통해 안전한 환경을 지속적으로 유지할 수 있습니다.
- 최신 보안 업데이트가 수행된 최신의 운영체제 이미지를 관리하고, 프로비저닝 후 서버 시작 시 자동으로 최신 업데이트를 수행을 자동화하도록 합니다.
- 컨테이너를 배포할 때 CI/CD 파이프라인에서 취약점 점검을 자동화합니다.
그러나 신뢰할 수 있는 레지스트리에서 이미지를 가져오더라도 사용하기 전에 서명을 확인하거나 취약성 스캔을 하지 않으면 보안 위험은 여전히 존재합니다.
또한 이미지를 강화했더라도 정기적으로 새로운 취약점을 테스트하거나 최신 버전으로 업데이트하지 않으면 강화된 이미지의 보안성이 점차 약화될 수 있습니다.
패치에만 의존하여 컴퓨팅 자원을 최신 상태로 유지하려고 하는 것도 문제가 될 수 있습니다.
시간이 지나면서 패치만으로는 강화된 기준에서 벗어나거나, 보안 이벤트 중에 위협 행위자가 설치한 맬웨어를 제거하지 못하는 상황이 발생할 수 있습니다.
따라서 정기적인 이미지 강화, 서명 검증, 취약성 스캔 및 업데이트는 필수적입니다.
접근 제어
Samsung Cloud Platform의 Virtual Server는 Key Pair를 통해 접근합니다.
Key Pair는 생성 시 한 번만 다운로드할 수 있습니다.


