오늘은 시스템 보안취약점에 대해 이야기 해보려고 합니다. 대신 특별하게 Nutanix 관점에서 한번 이야기 해볼께요. 경어체는 생략할께요 ~
"이거 로키 리눅스잖아요?" 어설픈 확신이 부른 재앙의 전조
IT 엔지니어들에게 신규 장비 납품은 설렘보다 고역에 가깝습니다. 특히 '보안 취약점 조치'라는 산을 넘어야 할 때는 더 그렇죠. 보통 KISA(한국인터넷진흥원) 가이드를 기준으로 수십 가지 항목을 일일이 대조해야 하는데, 이게 정말 영혼을 갉아먹는 작업이거든요. OS마다 설정값이 다르고, 일일이 스크립트 돌리다 보면 "도대체 왜 이런 건 자동화가 안 될까?"라는 탄식이 절로 나옵니다.
이번에도 그랬습니다. 뉴타닉스 클러스터를 납품하자마자 고객사 담당자분이 기다렸다는 듯이 다가오더군요. 손에는 깨알 같은 글씨가 적힌 보안 요구사항이 들려 있었습니다. "OOO님, SSH 포트 22번은 당연히 바꾸실 거죠? 그리고 관리자 계정도 정책상 새로 생성해야 합니다. 특정 유저만 프리즘에 접속하게 제한해 주시고요."
저는 머리가 띵했습니다. "담당자님, 이건 일반 리눅스가 아닙니다. 뉴타닉스 CVM은 커스터마이징된 가상화 클러스터 OS라 함부로 건드리면 시스템 전체가 무너집니다."라고 좋게 설명해 드렸죠. 그랬더니 그분은 비웃듯 터미널 창을 보여주시더라고요. "보세요. OS 명령어로 확인하니까 Rocky Linux라고 나오는데, 왜 안 된다는 건지 모르겠네요."
 |
| CVM OS를 확인한 결과.. |
SCMA, 당신이 잠든 사이에도 시스템을 되돌리는 터미네이터
여기서 우리는 아주 중요한 개념을 알아야 합니다. 바로 **SCMA(Security Configuration Management Automation)**라는 녀석이죠. 뉴타닉스 CVM은 겉보기엔 리눅스 같지만, 속은 철저하게 통제된 '어플라이언스'입니다. SCMA는 이 시스템의 유전자(설정값)가 변조되는 걸 실시간으로 감시하는 자가 치유 엔진입니다.
쉽게 비유해 볼까요? 당신이 CVM의 SSH 포트를 22번에서 다른 걸로 바꾼다고 칩시다. 그럼 SCMA는 이걸 '해킹'이나 '오설정'으로 간주합니다. 그리고는 당신이 잠든 사이, 혹은 설정을 마치고 돌아서는 순간 원래의 설정값으로 강제 복구해 버립니다. 문제는 이 과정에서 클러스터 내부의 노드끼리 서로를 찾지 못하게 된다는 겁니다. "너 누구야? 나랑 대화하던 22번 포트 어디 갔어?"라고 서로 소리를 지르다가 결국 클러스터 전체가 멘탈 붕괴(Hang)에 빠지는 거죠.
"뉴타닉스 CVM을 수동으로 수정하는 행위는, 달리는 자동차의 엔진을 주행 중에 분해 조립하겠다는 것과 다를 바 없습니다."
저는 이 SCMA의 위험성을 누누이 강조하고 철수했습니다. 하지만... 불길한 예감은 틀린 적이 없죠. 이틀 뒤 새벽, 전화벨이 요란하게 울렸습니다. "큰일 났습니다! 서비스가 다 죽었어요! 장비 불량인 것 같은데 빨리 와주세요!"
현장에서 발견한 '포트 20번'의 흔적, 그리고 휴먼 폴트
부리나케 달려가서 로그를 뒤졌습니다. 그런데 아니나 다를까, SSH 포트가 20번대로 변경되어 있더군요. 범인은 누구였을까요? 담당자분은 제 눈을 피하며 나지막이 속삭였습니다. "아니, 구글링 해보니까 바꿀 수 있을 것 같아서... 보안팀 지적사항이라 어쩔 수 없었습니다."
순간 화가 치밀어 올랐지만 꾹 참았습니다. 포트 변경으로 인해 CVM 간의 통신이 단절되었고, 하트비트(Heartbeat)가 끊기니 클러스터는 노드가 죽었다고 판단해 모든 서비스를 멈춰버린 겁니다. 이게 바로 우리가 가장 경계해야 할 '휴먼 폴트'의 전형입니다. "제가 수정 금지라고 말씀드리지 않았나요?"라는 말에 담당자분은 "그럼 어떻게 보안 검수를 통과하냐"며 멍한 표정을 짓더군요.
이 경험을 통해 알게 된 뉴타닉스 보안 꿀팁 (실패하지 않는 법)
- CVM은 블랙박스다: 일반 리눅스 보안 가이드를 들이밀지 마세요. 포트 변경, 관리자 계정 추가 생성 같은 '기본적인 것'들이 뉴타닉스에서는 '치명적인 것'이 됩니다.
- 로그 확인보다 정책 확인이 먼저: CVM 내부 설정을 바꾸기 전에 반드시 Nutanix 공식 문서의 'Security Guide'를 확인하세요. 허용되지 않은 수정은 자가 복구 로직에 의해 반드시 장애를 유발합니다.
- 기술 공문을 무기로 써라: 보안팀을 설득하는 가장 좋은 방법은 엔지니어의 말이 아니라 제조사의 '직인'이 찍힌 문서입니다.
엔지니어의 수명을 늘려주는 '공문 한 장'의 마법
결국 저는 방법을 바꿨습니다. 고객과 싸우는 대신 제조사(Nutanix) 본사에 정식으로 기술 지원을 요청했죠. "이 시스템은 설계상 특정 보안 항목을 수동으로 조치할 수 없으며, 이미 STIG(보안 기술 구현 지침)를 충족하고 있다"는 내용의 공식 공문을 받아냈습니다.
그 종이 한 장을 고객사 보안팀에 제출하자마자 그 모든 소란이 잠잠해졌습니다. "아, 제조사에서 안 된다고 하면 어쩔 수 없죠."라는 답변과 함께요. 수십 시간을 들여 포트를 바꾸고 계정을 생성하느라 삽질했던 시간이 허무하게 느껴질 정도로 간단한 해결책이었습니다. 덕분에 고객사 담당자분도 보안 감점 없이 무사히 넘어가게 되었고, 저도 더 이상의 새벽 호출에서 해방될 수 있었죠.
항상 납품하러 갈 때마다 느낍니다. 열심히 일하는 것보다 더 중요한 건 '융통성'과 '정확한 증빙'이라는걸요. 보안 조치가 불가능한 항목을 억지로 고치려 들지 마세요. 대신 왜 안 되는지를 증명할 수 있는 문서를 먼저 챙기십시오. 그게 여러분의 퇴근 시간을 지켜주는 가장 강력한 방패가 될 겁니다.
오늘 이 이야기가 현장에서 고군분투하는 동료 엔지니어 분들에게 작은 힌트가 되었으면 좋겠네요. 우리, 몸 상해가면서 일하지 말자고요!
요즘 같은 세상에서 살아남기 힘든 필드 엔지니어 분들 힘내세요! 격려합니다.
0 댓글