[OpenStack] OpenStack 프라이빗 클라우드 보안 강화: 최신 감사 보고서 분석 및 대응 전략

목차

• 1. 왜 감사에서 늘 같은 항목이 걸릴까요?
• 2. OpenStack 보안 베스트 프랙티스, 핵심만 먼저 잡아보겠습니다
• 3. 실전 구현 1: 계정, 엔드포인트, TLS부터 정리합니다
• 4. 실전 구현 2: RabbitMQ, 로그, 이미지 무결성을 같이 보셔야 합니다
• 5. 실전 구현 3: 파일 권한과 노드 하드닝은 기본인데 가장 많이 놓칩니다
• 6. ⚠️ 감사 때 자주 터지는 트러블슈팅
• 6-1. HTTPS는 켰는데 인증 실패가 납니다
• 6-2. 내부 통신을 HTTPS로 바꾸니 서비스 등록은 됐는데 호출이 꼬입니다
• 6-3. 로그는 모이는데 감사 보고서에서 추적성이 부족하다고 나옵니다
• 6-4. 보안 강화 후 성능이 걱정됩니다
• 7. 검증은 이렇게 하시면 됩니다
• 8. 정리: OpenStack 프라이빗 클라우드 보안은 순서가 중요합니다
• 9. 자주 묻는 질문
• Q1. 작은 홈랩에도 이렇게까지 해야 할까요?
• Q2. 클라우드 보안 감사에서 가장 빨리 점수 올리는 항목은 뭔가요?
• Q3. OpenStack 보안 베스트 프랙티스를 어디서 시작하면 좋을까요?

[인프라] OpenStack 프라이빗 클라우드 보안 강화 대응 전략

OpenStack 프라이빗 클라우드 보안 이야기는 평소엔 좀 뒤로 밀리기 쉽습니다. 서비스가 잘 돌고 있으면 당장 체감이 안 되거든요. 그런데 클라우드 보안 감사 한 번 들어오면 분위기가 바로 달라집니다. 계정 정책, API TLS, 로그 보관, 이미지 무결성 같은 항목이 한꺼번에 쏟아지니까요. 저도 홈랩과 실무 환경에서 비슷한 점검을 여러 번 겪어봤는데, 처음엔 “이건 설정 파일 몇 개만 손보면 되겠지” 싶었거든요. 근데 막상 들어가 보니 Keystone(키스톤, 인증/인가), Nova(노바, 컴퓨트), Neutron(뉴트론, 네트워크), RabbitMQ(래빗MQ, 메시지 브로커)까지 서로 얽혀 있어서 삽질 좀 했습니다 ㅎㅎ

이번 글은 특정 벤더 보고서 하나를 요약하는 방식보다는, 최근 감사에서 반복적으로 지적되는 OpenStack 보안 항목을 공식 Security Guide와 체크리스트 기준으로 묶어서 정리한 내용입니다. 즉, 보고서가 달라도 결국 자주 걸리는 포인트는 비슷하더라고요. 그래서 오늘은 OpenStack 프라이빗 클라우드 보안을 실제 운영 관점에서 어떻게 강화할지, 제가 실무에서 우선순위를 잡는 방식으로 풀어보겠습니다.

컨트롤 플레인, 컴퓨트 노드, 스토리지, 관리망과 외부망을 분리한 OpenStack 보안 아키텍처 예시입니다.

1. 왜 감사에서 늘 같은 항목이 걸릴까요?

쉽게 말해 감사는 “설정이 있느냐”보다 보안 경계(Security Boundary, 보안 경계)가 실제로 분리되어 있느냐를 봅니다. OpenStack은 컴포넌트가 많아서, 한 군데만 HTTPS를 켰다고 끝나지 않거든요. 예를 들어 Horizon(호라이즌, 대시보드)은 TLS를 쓰는데 서비스 간 내부 통신은 평문으로 남아 있거나, RabbitMQ 인증서는 넣었는데 호스트네임 검증은 꺼져 있는 식입니다. 겉으로는 안전해 보여도 감사에서는 바로 티가 납니다.

제가 최근 점검할 때도 지적이 많이 나온 항목은 아래 네 가지였습니다.

• 관리망과 외부망 분리 부족: 내부 API가 외부 엔드포인트를 타는 경우
• 과도한 권한: 관리자 계정 공유, 서비스 계정 권한 과다
• 로그는 있는데 감사 추적이 어려움: 중앙 수집과 상관분석 부재
• 이미지/메시지 경로 무결성 미흡: 이미지 서명 검증, 메시지 브로커 TLS 검증 미설정

2. OpenStack 보안 베스트 프랙티스, 핵심만 먼저 잡아보겠습니다

OpenStack 보안 베스트 프랙티스를 한 줄로 줄이면 이겁니다. “외부 공개 구간만 막지 말고, 내부 제어면(Control Plane, 제어 평면)까지 신뢰하지 말자.” 저도 처음엔 내부망이면 괜찮지 않나 싶었는데, 실제로는 운영자 실수나 계정 탈취가 더 무섭더라고요.

감사 항목	자주 보이는 문제	즉시 대응	장기 대응
인증/인가	관리자 계정 공유, MFA 미적용	관리자 계정 분리, 외부 IdP 연동 검토	RBAC 재설계, 페더레이션 적용
통신 보안	내부 API 평문, 인증서 검증 비활성화	HTTPS 강제, internal endpoint 지정	전 구간 TLS, 인증서 수명주기 자동화
감사 로그	노드별 로그 분산, 이벤트 표준화 부족	중앙 로그 수집	CADF 기반 감사 추적 체계화
무결성	이미지 검증 없음, 설정 파일 변경 감시 없음	서명 검증, 권한 점검	FIM, 골든 이미지 파이프라인

여기서 중요한 포인트! 감사 대응은 문서부터 쓰는 게 아니라 데이터 흐름부터 그려야 합니다. 누가 로그인하고, 어떤 API를 타고, 어떤 메시지 브로커를 지나, 최종적으로 어떤 로그가 남는지 보셔야 합니다. 이 흐름이 안 보이면 체크리스트만 돌려도 자꾸 빠지는 항목이 생깁니다.

3. 실전 구현 1: 계정, 엔드포인트, TLS부터 정리합니다

제가 직접 해보니 제일 효과가 큰 첫 단계는 “접속면 줄이기”였습니다. 즉, 공개 엔드포인트와 내부 엔드포인트를 분리하고, 서비스 간 통신이 public URL이 아니라 internal URL을 쓰도록 강제하는 겁니다.

1. 서비스 카탈로그(Service Catalog, 서비스 목록)에서 internal endpoint를 분리합니다.
2. 각 서비스 설정에서 Keystone 인증 URL과 연동 URL이 HTTPS인지 확인합니다.
3. insecure = false 여부를 전부 확인합니다.

openstack endpoint list --long
openstack endpoint create identity --region RegionOne internal https://keystone.internal.example:5000/v3
openstack endpoint create image --region RegionOne internal https://glance.internal.example:9292
openstack endpoint create network --region RegionOne internal https://neutron.internal.example:9696

# /etc/nova/nova.conf
[keystone_authtoken]
www_authenticate_uri = https://keystone.internal.example:5000
auth_url = https://keystone.internal.example:5000
insecure = false

[glance]
api_servers = https://glance.internal.example:9292

이 작업은 단순해 보여도 효과가 큽니다. 내부 관리 트래픽이 외부 공개 주소를 타지 않게 되니까요. 특히 프록시나 로드밸런서가 여러 겹일 때 감사 추적도 훨씬 쉬워집니다.

public endpoint와 internal endpoint를 분리하고 서비스 간 통신을 HTTPS로 고정한 예시 구성입니다.

4. 실전 구현 2: RabbitMQ, 로그, 이미지 무결성을 같이 보셔야 합니다

OpenStack은 API만 안전해도 끝이 아닙니다. 실제로 서비스끼리 대화하는 길목은 RabbitMQ 같은 메시지 브로커인 경우가 많거든요. 여기 TLS를 켜도 인증서 체인만 보고 호스트네임 검증을 안 하면 허점이 남습니다. 최근 oslo.messaging 릴리스 노트에서도 이 부분이 분명히 언급됐습니다. 그래서 제가 운영할 때는 브로커 TLS와 로그 표준화를 같이 묶어서 봅니다.

# /etc/nova/nova.conf 또는 공통 oslo.messaging 설정
[oslo_messaging_rabbit]
ssl = true
ssl_ca_file = /etc/ssl/certs/openstack-ca.pem
ssl_cert_file = /etc/ssl/certs/client.pem
ssl_key_file = /etc/ssl/private/client-key.pem
ssl_enforce_hostname_verification = true

단, 이 옵션은 배포판 패키지 버전에 따라 지원 여부가 다를 수 있습니다. 그래서 바로 적용하기 전에 패키지 changelog나 릴리스 노트를 꼭 보셔야 합니다. 저도 이거 모르고 넣었다가 서비스 재시작만 반복한 적이 있었네요.

감사 로그 쪽은 Keystone의 CADF(Cloud Auditing Data Federation, 클라우드 감사 이벤트 표준) 포맷을 적극 검토할 만합니다. 사람이 보기엔 조금 딱딱하지만, SIEM(보안 정보 이벤트 관리)으로 넘길 때 훨씬 정리가 잘 됩니다.

# /etc/keystone/keystone.conf
[DEFAULT]
notification_format = cadf

그리고 이미지 무결성도 자주 빠뜨립니다. Glance(글랜스, 이미지 서비스)와 Nova에서 서명 검증 흐름을 넣어두면, 검증되지 않은 이미지 부팅을 줄일 수 있습니다.

# /etc/nova/nova.conf
[glance]
verify_glance_signatures = true

처음엔 이게 너무 과한가 싶었는데, 골든 이미지(Golden Image, 표준 이미지)를 운영하는 환경에서는 진짜 편하더라고요. 누가 어떤 이미지를 올렸는지, 검증됐는지 흐름이 분명해집니다.

메시지 브로커 TLS 보호와 Keystone CADF 감사 로그가 중앙 수집 시스템으로 모이는 흐름입니다.

5. 실전 구현 3: 파일 권한과 노드 하드닝은 기본인데 가장 많이 놓칩니다

이건 너무 기본 같아서 오히려 빼먹습니다. 그런데 공식 Security Checklist를 보면 Keystone, Nova, Neutron 설정 파일의 소유권과 권한을 아주 명확하게 확인하라고 하거든요. 감사에서도 이건 빠지지 않습니다.

stat -L -c "%U %G %a" /etc/keystone/keystone.conf
stat -L -c "%U %G %a" /etc/nova/nova.conf
stat -L -c "%U %G %a" /etc/neutron/neutron.conf
find /etc/keystone /etc/nova /etc/neutron -type f -perm /027 -ls

제가 주로 보는 기준은 이렇습니다.

• 서비스 계정과 그룹이 올바른지 확인
• 설정 파일 권한이 과도하게 열려 있지 않은지 확인
• SELinux(셀리눅스, 강제 접근 통제)나 AppArmor 정책과 충돌 없는지 확인
• FIM(File Integrity Management, 파일 무결성 감시) 대상에 핵심 설정 파일 포함

여기서 많이 겪는 문제는 자동화 도구가 재배포하면서 권한을 널널하게 바꿔버리는 경우입니다. 특히 템플릿 한 군데 잘못 두면 전체 노드가 같은 실수를 반복합니다. 그래서 저는 배포 후 검증 명령을 CI 파이프라인이나 운영 점검 스크립트에 꼭 넣습니다.

6. ⚠️ 감사 때 자주 터지는 트러블슈팅

이 섹션은 실전에서 진짜 많이 부딪히는 부분입니다.

6-1. HTTPS는 켰는데 인증 실패가 납니다

대부분 CA 체인이나 호스트네임 불일치입니다. 인증서를 넣었다고 끝이 아니고, 서비스가 접속하는 URL과 인증서 SAN(Subject Alternative Name, 주체 대체 이름)이 맞아야 합니다.

6-2. 내부 통신을 HTTPS로 바꾸니 서비스 등록은 됐는데 호출이 꼬입니다

이 경우 public endpoint는 바꿨는데, 개별 서비스 설정은 여전히 외부 주소를 보고 있는 경우가 많습니다. 카탈로그와 각 서비스 설정 파일을 둘 다 봐야 합니다.

6-3. 로그는 모이는데 감사 보고서에서 추적성이 부족하다고 나옵니다

이건 단순 보관이 아니라 상관관계(Correlation, 상관 분석) 문제입니다. 사용자 로그인, 토큰 발급, 인스턴스 생성, 볼륨 연결, 보안그룹 변경 이벤트를 하나의 흐름으로 이어서 볼 수 있어야 하거든요. 그래서 Keystone 이벤트, API 로그, 하이퍼바이저 로그를 따로 보지 말고 묶어야 합니다.

6-4. 보안 강화 후 성능이 걱정됩니다

맞습니다. TLS와 추가 로깅은 비용이 있습니다. 그래서 저는 처음부터 전부 켜기보다 인터넷 노출 구간, 관리자 구간, 메시지 브로커, 이미지 검증 순서로 우선순위를 잡습니다. 한 번에 다 바꾸면 장애 원인 분석이 어려워집니다.

7. 검증은 이렇게 하시면 됩니다

보안 설정은 “넣었다”가 아니라 “검증됐다”로 끝내야 합니다. 제가 보통 마지막에 확인하는 체크는 아래와 같습니다.

1. 모든 핵심 서비스 엔드포인트가 HTTPS인지 확인
2. 서비스 설정의 insecure = true 흔적 제거 확인
3. 메시지 브로커 TLS 연결 및 인증서 검증 확인
4. CADF 또는 중앙 로그에서 관리자 행위 추적 가능 여부 확인
5. 서명되지 않은 이미지가 정책상 차단되는지 확인

openstack endpoint list --long | egrep "https|Region"
grep -R "insecure *= *true" /etc/keystone /etc/nova /etc/neutron /etc/glance
openssl s_client -connect rabbitmq.internal.example:5671 -servername rabbitmq.internal.example
openstack image list
openstack server list

완료 후 대시보드와 CLI 둘 다 테스트해보세요. Horizon만 되고 CLI가 안 되거나, 반대로 API는 되는데 메타데이터 프록시가 깨지는 경우가 있습니다. 저도 이 단계에서 “드디어 됐다!” 했다가 보안그룹 갱신이 안 되는 걸 뒤늦게 발견한 적이 있었거든요.

보안 점검 항목이 통과되고 중앙 로그에서 관리자 행위를 추적할 수 있는 결과 화면 예시입니다.

8. 정리: OpenStack 프라이빗 클라우드 보안은 순서가 중요합니다

OpenStack 프라이빗 클라우드 보안은 기능을 많이 넣는 게임이 아닙니다. 순서를 잘 잡는 작업에 가깝습니다. 제가 실제로 운영하면서 느낀 우선순위는 이렇습니다. 계정 통제 → 내부 API TLS → 메시지 브로커 보호 → 감사 로그 표준화 → 이미지 무결성 → 파일 무결성 감시. 이 순서로 가면 감사 대응도 수월하고, 장애가 나도 어디서 꼬였는지 찾기 편합니다.

혹시 지금 프라이빗 클라우드 감사 대응을 준비 중이시라면, 문서부터 만들기보다 먼저 엔드포인트와 계정, 로그 흐름을 그림으로 그려보세요. 그 다음에 체크리스트를 맞추면 훨씬 빨라집니다. 다음 글에서는 Barbican(바비칸, 비밀 관리 서비스)과 이미지 서명 체계를 조금 더 깊게 다뤄보겠습니다. 이전에 정리한 리눅스 하드닝 글이 있으시면 그 흐름과 같이 보셔도 연결이 잘 됩니다.

계정 통제, TLS, 로그, 이미지 무결성, 파일 무결성 감시 순서로 정리한 대응 우선순위 요약입니다.

9. 자주 묻는 질문

Q1. 작은 홈랩에도 이렇게까지 해야 할까요?

전부 한 번에 할 필요는 없습니다. 다만 관리자 계정 분리, HTTPS, 설정 파일 권한 점검은 작은 환경에서도 바로 체감됩니다.

Q2. 클라우드 보안 감사에서 가장 빨리 점수 올리는 항목은 뭔가요?

보통은 내부 API TLS, 관리자 접근 통제, 중앙 로그 수집입니다. 이 세 개가 눈에 잘 보이고 재현도 쉽습니다.

Q3. OpenStack 보안 베스트 프랙티스를 어디서 시작하면 좋을까요?

공식 Security Checklist를 서비스별로 돌려보는 게 제일 현실적입니다. Keystone, Nova, Neutron부터 보시면 됩니다.

📚 함께 읽으면 좋은 글

• 테넌트 쿼터로 클라우드 비용 효율화하기
• OpenStack 업그레이드 10가지 체크리스트: 실전 베스트 프랙티스로 성공 확률 높이기
• OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드
• EKS 운영 비용 최적화 전략: 클라우드 지출 효율 높이기
• Crossplane 장애 사례로 배우는 멀티 클라우드 인프라 관리