[클라우드 보안] OpenStack 보안 그룹 취약점과 Floating IP 보안 강화 전략

목차

• 1. 왜 이 이슈를 다시 봐야 하나요
• 2. OpenStack 보안 그룹 취약점, 쉽게 말해 뭐가 문제인가요
• 3. 공식 문서 기준으로 봐야 할 핵심 포인트
• 4. 실전 구현: Floating IP 보안 강화 체크리스트
• 4-1. 현재 노출 범위부터 확인하기
• 4-2. 보안 그룹을 최소 허용(Least Privilege)으로 다시 자르기
• 4-3. 특정 Floating IP 직접 지정 권한 줄이기
• 4-4. 예외 기능 점검하기: Port Security와 Allowed Address Pairs
• 4-5. 침해 대응 절차는 "FIP 분리"로 끝내지 않기
• 5. ⚠️ 실제 운영에서 자주 겪는 문제와 해결법
• 6. 검증: 강화 후 무엇을 확인해야 하나요
• 7. 운영 기준으로 정리하는 Floating IP 보안 원칙
• 8. 자주 묻는 질문과 마무리
• Q1. Floating IP를 떼면 외부 접근은 즉시 끝나는 것 아닌가요?
• Q2. 이 이슈가 곧바로 최신 CVE라는 뜻인가요?
• Q3. 가장 먼저 적용할 한 가지는 뭔가요?

[클라우드 보안] OpenStack 보안 그룹 취약점과 Floating IP 보안 강화 전략

OpenStack 운영하다 보면 제일 많이 방심하는 지점 중 하나가 바로 보안 그룹(Security Group, 가상 방화벽 정책)과 Floating IP(플로팅 IP, 공인 IP를 인스턴스에 동적으로 붙이는 기능) 조합이에요. 저도 홈랩이랑 사내 테스트 환경에서 처음 이 구조를 만졌을 때는 "보안 그룹만 잘 걸어두면 끝 아닌가?" 싶었는데, 실제로 뜯어보면 그렇지 않더라고요. 특히 OpenStack 보안 그룹 취약점이라고 검색해서 들어오신 분들이라면, 단순히 룰 몇 개 추가하는 수준이 아니라 연결 상태(state), NAT(Network Address Translation, 네트워크 주소 변환), 정책 권한까지 같이 봐야 한다는 게 핵심이에요.

이번 글은 2014년에 공개된 OpenStack Security Note OSSN-0020에서 다뤄진 Floating IP 분리 후 기존 NAT 연결이 살아남는 문제, 그리고 2022년 이후에도 논의된 특정 Floating IP 지정 시 외부 네트워크 게이트웨이 IP와 충돌할 수 있는 운영 리스크를 바탕으로 정리했어요. 즉, 새로운 미확인 이슈를 다루는 게 아니라, 실제로 문서화된 동작과 운영상 취약 지점을 기준으로 Floating IP 보안 전략을 재구성한 분석입니다.

보안 그룹, Neutron 라우터, 외부 네트워크, 인스턴스 사이의 트래픽 흐름을 한눈에 보여주는 개요 이미지가 들어갈 자리입니다.

1. 왜 이 이슈를 다시 봐야 하나요

공식 보안 노트 OSSN-0020은 Neutron L3 agent 환경에서 Floating IP를 해제해도 이미 맺어진 연결(established connection)은 바로 끊기지 않을 수 있다고 설명해요. 쉽게 말해, 운영자는 "공인 IP를 떼었으니 외부 접근도 끝났다"고 생각했는데, 실제 세션은 계속 살아 있는 상황이 생길 수 있다는 뜻이거든요.

이게 위험한 이유는 장애 대응이나 침해 대응 때 판단을 잘못하게 만들기 때문이에요. 예를 들어 외부에서 SSH가 붙어 있던 인스턴스에서 이상 행위가 발견돼서 Floating IP만 급하게 떼는 경우가 있잖아요. 저도 예전에 비슷하게 대응했다가, "어? 왜 세션이 안 죽지?" 하고 한참 봤던 적이 있어요. 나중에야 알았는데 보안 그룹 정책과 Floating IP 분리만으로 세션 종료가 보장되지 않는다는 게 핵심이었거든요.

2. OpenStack 보안 그룹 취약점, 쉽게 말해 뭐가 문제인가요

보안 그룹(Security Group)은 Neutron 포트에 붙는 가상 방화벽이에요. 기본적으로 Ingress(인그레스, 외부에서 안으로 들어오는 트래픽)는 막고, Egress(이그레스, 내부에서 바깥으로 나가는 트래픽)는 허용하는 구성이 많아요. 문서 기준으로도 보안 그룹은 포트 단위로 적용되고, 여러 그룹이 붙으면 룰은 가산적(additive)으로 합쳐진답니다.

문제는 여기서 Floating IP가 끼어들 때 생겨요. Floating IP는 인스턴스 NIC에 공인 IP를 직접 꽂는 느낌이라기보다, 대개 Neutron 라우터의 NAT 경로를 통해 외부와 연결돼요. 그래서 정책을 바꿨다고 해서 이미 형성된 세션이 운영자가 기대하는 순간에 깔끔하게 정리되는 건 아닐 수 있다는 뜻이에요.

정리하면 OpenStack 보안 그룹 취약점은 단순히 "룰이 뚫린다"가 아니라, 다음처럼 여러 층에서 나타나요:

• 상태 기반 연결 잔존: Floating IP를 떼어도 기존 세션이 남을 수 있어요.
• 과도한 권한: 특정 public IP를 사용자가 직접 지정하게 두면 외부 네트워크와 충돌 가능성이 생겨요.
• 예외 기능 남용: allowed-address-pairs나 port_security 예외를 잘못 쓰면 정책 의미가 흐려져요.
• 운영 착시: 콘솔에서 "분리됨"으로 보여도 실제 통신은 곧바로 끊기지 않을 수 있어요.

3. 공식 문서 기준으로 봐야 할 핵심 포인트

항목	확인된 사실	운영 의미
OSSN-0020	Floating IP 분리 후 기존 NAT 연결이 남을 수 있음	침해 대응 시 FIP 분리만으로 종료 판단하면 위험
보안 그룹 기본 동작	포트 단위 적용, 룰은 가산적 적용	인스턴스 단위로만 생각하면 누락이 생겨요
Neutron 정책	create_floatingip:floating_ip_address 권한을 정책으로 제어 가능	특정 공인 IP 직접 지정 권한을 축소할 수 있어요
Allowed Address Pairs	특정 조건에서 원격 그룹 기반 제한을 우회할 수 있다는 경고 존재	예외 기능은 최소화해야 해요
정책 파일 형식	JSON 정책 파일은 deprecated, YAML 권장	하드닝 작업은 policy.yaml 기준으로 정리하는 게 안전해요

제가 직접 문서랑 버그 토론을 다시 읽어보니, 많은 분이 "이게 CVE냐 아니냐"에만 집중하시더라고요. 근데 운영자 입장에서는 그보다 지금 내 클라우드에서 어떤 권한과 어떤 연결이 실제로 남느냐가 훨씬 중요해요. 특히 Floating IP 보안은 네트워크 설계, 테넌트 권한, 대응 절차를 같이 봐야 실수가 줄어들거든요.

4. 실전 구현: Floating IP 보안 강화 체크리스트

4-1. 현재 노출 범위부터 확인하기

처음엔 화려한 정책부터 만지지 마시고, 현재 어떤 인스턴스가 외부로 열려 있는지부터 봐야 해요. 이 단계 건너뛰면 진짜 자주 꼬여요.

openstack floating ip list
openstack server list --long
openstack port list --server <SERVER_NAME>
openstack security group list
openstack security group rule list <SECURITY_GROUP_NAME>

여기서 확인할 건 세 가지예요:

1. 어떤 인스턴스에 Floating IP가 붙어 있는지
2. 해당 포트에 어떤 보안 그룹이 붙어 있는지
3. 0.0.0.0/0 같은 광범위 Ingress 규칙이 있는지

4-2. 보안 그룹을 최소 허용(Least Privilege)으로 다시 자르기

SSH, HTTPS처럼 꼭 필요한 포트만 열고, 출발지 IP도 가능한 한 좁게 잡는 게 가장 실효성 있어요. 기본처럼 들리지만 체감 효과가 정말 크거든요.

openstack security group create web-tight
openstack security group rule create web-tight \
  --ingress --ethertype IPv4 --protocol tcp --dst-port 22 \
  --remote-ip 203.0.113.10/32
openstack security group rule create web-tight \
  --ingress --ethertype IPv4 --protocol tcp --dst-port 443 \
  --remote-ip 0.0.0.0/0

운영 환경이면 22번도 bastion host(배스천 호스트, 점프 서버) 대역으로 더 좁히는 걸 권해요. 저도 처음엔 귀찮아서 넓게 열었다가, 나중에 로그 뒤지면서 후회했거든요.

실전 구현 단계에서 보안 그룹을 최소 허용 형태로 재구성하는 흐름을 설명하는 이미지가 들어갈 자리입니다.

4-3. 특정 Floating IP 직접 지정 권한 줄이기

Neutron 정책 문서를 보면 create_floatingip:floating_ip_address 권한을 따로 제어할 수 있어요. 이게 중요한 이유가 있거든요. Launchpad에 2022년 등록된 논의에서는, 사용자가 특정 IP를 수동 지정할 때 외부 네트워크의 게이트웨이 IP와 같은 값을 요청할 수 있는 운영 리스크가 지적됐어요. 이건 문서상 "무조건 취약점"으로 확정된 CVE는 아니지만, 운영 사고로 번질 수 있는 위험한 설계 포인트가 맞아요.

그래서 실무에서는 보통 임의의 공인 IP 지정 권한을 일반 사용자에게 열어두지 않는 쪽이 낫더라고요.

# /etc/neutron/policy.yaml
create_floatingip: "(rule:admin_only) or (role:member and project_id:%(project_id)s)"
create_floatingip:floating_ip_address: "rule:admin_only"
update_floatingip: "(rule:admin_only) or (role:member and project_id:%(project_id)s)"
delete_floatingip: "(rule:admin_only) or (role:member and project_id:%(project_id)s)"

이렇게 하면 일반 테넌트 사용자는 Floating IP 자체는 할당받되, 특정 공인 IP를 집어서 요청하는 행위는 막을 수 있어요. OpenStack 보안 강화 관점에서 생각보다 효과가 커요.

4-4. 예외 기능 점검하기: Port Security와 Allowed Address Pairs

여기서 많이 놓치는 게 Port Security(포트 보안)예요. 어떤 포트가 --disable-port-security 상태면 보안 그룹 기대치가 달라질 수 있거든요. 그리고 OpenStack API 문서에는 allowed-address-pairs를 특정 방식으로 쓰면, 같은 보안 그룹을 쓰는 포트들에 대해 source IP 제한 성격의 룰 우회가 가능하다는 경고도 있어요.

openstack port show <PORT_ID> -f yaml
openstack port list --long
openstack port set --enable-port-security <PORT_ID>

물론 실제 적용 전에는 LB(Load Balancer, 로드밸런서), VRRP, VIP 같은 예외 설계가 있는지 꼭 확인하셔야 해요. 이 부분 모르고 일괄 적용하면 서비스가 바로 흔들려요. 저도 HA 테스트하다가 VIP가 안 떠서 한참 봤던 기억이 있네요.

4-5. 침해 대응 절차는 "FIP 분리"로 끝내지 않기

이 부분이 제일 중요해요. OSSN-0020 기준으로는, Neutron L3 agent 환경에서 Floating IP를 분리해도 기존 연결이 남을 수 있거든요. 그러니까 의심 세션 차단이 목적이라면 절차를 이렇게 가져가야 한다는 뜻이에요:

1. 인스턴스 상태 확인
2. 필요 시 인스턴스 정지 또는 종료
3. 그 다음 Floating IP 분리
4. 재기동 후 필요한 보안 그룹만 재적용

openstack server stop <SERVER_NAME>
openstack server remove floating ip <SERVER_NAME> <FLOATING_IP>
openstack server start <SERVER_NAME>

환경에 따라 완전 종료 대신 격리 네트워크로 포트를 옮기는 방식도 쓰지만, 최소한 Floating IP만 떼고 끝났다 판단하는 건 위험해요.

5. ⚠️ 실제 운영에서 자주 겪는 문제와 해결법

• 문제 1: 보안 그룹 룰은 지웠는데 세션이 살아 있어요.
  해결: 기존 연결 추적 상태를 의심해야 해요. 긴급 대응이면 인스턴스 정지/격리까지 포함해 절차를 바꾸는 게 안전해요.
• 문제 2: 특정 테넌트가 이상한 공인 IP를 요청해요.
  해결: create_floatingip:floating_ip_address 권한을 축소하고, 직접 지정 대신 자동 할당만 허용하세요.
• 문제 3: 포트 보안 예외 때문에 정책 검증이 안 맞아요.
  해결: port_security_enabled, allowed_address_pairs, 보안 그룹 바인딩 상태를 같이 점검하세요.
• 문제 4: "기본 보안 그룹이 있으니 괜찮겠지"라고 생각해요.
  해결: 기본 그룹은 출발점일 뿐이에요. 워크로드별 전용 그룹으로 분리하는 게 맞아요.

혹시 이런 경험 있으신가요? 콘솔에는 아무 문제 없어 보이는데 실제 네트워크는 다르게 움직이는 상황이요. OpenStack 네트워킹은 특히 이런 "보이는 상태와 실제 데이터 플레인 상태의 차이"가 자주 나타나거든요.

6. 검증: 강화 후 무엇을 확인해야 하나요

설정하고 끝내면 안 돼요. 검증이 없으면 보안은 그냥 희망사항이거든요.

openstack floating ip list --long
openstack security group rule list web-tight
openstack port show <PORT_ID> -f yaml
openstack server show <SERVER_NAME>

1. Floating IP가 정말 필요한 인스턴스에만 붙어 있는지 확인하세요.
2. 보안 그룹 Ingress 규칙이 최소 범위인지 다시 봐요.
3. Port Security가 예외 없이 켜져 있는지 점검해요.
4. 의심 인스턴스는 FIP 제거 후 기존 세션이 끊겼는지 운영 절차로 검증하세요.

추가로 가능하다면 FWaaS(Firewall-as-a-Service, 서비스형 방화벽)나 외부 방화벽 계층을 같이 두는 것도 좋아요. 보안 그룹만으로 모든 걸 해결하려고 하면 경계 보안이 얇아져요. 특히 클라우드 보안은 "한 겹 더"가 생각보다 큰 차이를 낸다고 느껴봤거든요.

적용 전후로 외부 노출 범위가 어떻게 줄었는지 보여주는 결과 검증 이미지가 들어갈 자리입니다.

7. 운영 기준으로 정리하는 Floating IP 보안 원칙

원칙	권장 여부	이유
모든 VM에 Floating IP 부여	비권장	공격 표면이 불필요하게 넓어져요.
특정 공인 IP 직접 지정 허용	제한 권장	외부 네트워크와 충돌할 여지를 줄일 수 있어요.
보안 그룹 최소 허용 구성	강력 권장	실수 범위를 가장 확실하게 줄여요.
Port Security 예외 최소화	강력 권장	정책 일관성이 깨지는 걸 막아요.
침해 대응 시 인스턴스 정지 포함	권장	기존 연결 잔존 위험에 대응할 수 있어요.

제가 직접 운영하면서 느낀 건, Floating IP 보안은 네트워크 팀 일만도 아니고, 클라우드 플랫폼 팀 일만도 아니라는 거예요. 권한 정책, 라우팅/NAT 동작, 테넌트 가이드, 대응 플레이북이 같이 맞물려야 드디어 안정된다는 느낌이 들어요. 드디어 됐다 싶을 때도 꼭 한 번 더 검증하는 게 좋거든요.

8. 자주 묻는 질문과 마무리

Q1. Floating IP를 떼면 외부 접근은 즉시 끝나는 것 아닌가요?

그렇지 않아요. 최소한 OSSN-0020에서 설명된 Neutron L3 agent 동작 기준으로는 기존 연결이 남을 수 있거든요.

Q2. 이 이슈가 곧바로 최신 CVE라는 뜻인가요?

그건 아니에요. 이 글은 공식 보안 노트와 문서화된 동작, 그리고 운영상 재현 가능한 위험 지점을 분석한 글이거든요.

Q3. 가장 먼저 적용할 한 가지는 뭔가요?

제라면 특정 Floating IP 직접 지정 권한 제한과 0.0.0.0/0 Ingress 축소부터 하겠어요. 체감 효과가 정말 커요.

보안 그룹 최소 허용, 정책 권한 제한, 포트 보안 점검, 대응 절차 개선을 요약한 인포그래픽이 들어갈 자리입니다.

정리해보면, OpenStack 보안 그룹 취약점을 볼 때 핵심은 "보안 그룹 룰이 있느냐"가 아니라 "그 룰이 실제 연결 종료와 권한 통제까지 보장하느냐"예요. Floating IP는 정말 편해요. 근데 편한 만큼 공격 표면도 넓어지거든요. 이번 기회에 외부 노출 인스턴스 목록, 보안 그룹 예외, policy.yaml 권한까지 한 번에 점검해보시면 좋겠어요.

다음 글에서는 OpenStack 보안 강화 관점에서 RBAC(Role-Based Access Control, 역할 기반 접근 제어)와 프로젝트별 네트워크 분리 전략도 이어서 다뤄볼 계획이에요. 이전 글에서 다뤘던 bastion 구조와 함께 보시면 더 이해가 잘 될 겁니다.

📚 함께 읽으면 좋은 글

• OpenStack Designate 마이그레이션: 기존 DNS 연동 전략
• OpenStack Placement 벤치마크: 대규모 자원 할당 성능 분석
• OpenStack Ceph 연동 실패 사례와 스토리지 성능 최적화 교훈
• 최신 보안 취약점 CVE 분석: 기업 패치 관리 자동화 전략
• OpenVAS 활용 취약점 스캔 효율성 높이는 10가지 체크리스트