[기획/미토스 이후, 취약점 대응②] 서비스 멈추지 않고 빠르게 패치하려면

앤트로픽의 인공지능(AI) 모델 미토스를 기점으로 AI의 소프트웨어 취약점 탐색 능력이 빠르게 발전하고 있다. AI가 대량의 취약점을 찾고 공격 코드까지 만들 수 있게 되면서, 이를 어떻게 빠르게 분석·검증하고 대응·관리할지가 주요 과제로 떠올랐다. 바이라인네트워크는 ‘미토스 이후, 취약점 대응’ 기획 시리즈로 AI 이후 취약점 관리와 대응 체계가 어떻게 달라져야 하는지를 기업 현장의 관점에서 살펴본다. 두 번째 회에서는 외부 접점이 많고 24시간 서비스를 운영해 취약점 악용 위험과 패치 장애 부담을 함께 안고 있는 금융·플랫폼 기업을 중심으로, 서비스를 멈추지 않고 패치를 안전하고 빠르게 적용하는 방법을 짚어봤다. <편집자 주>

[미토스 이후, 취약점 대응①] 취약점 쏟아져도, 패치는 느린 이유
[미토스 이후, 취약점 대응②] 서비스 멈추지 않고 빠르게 패치하려면 (이번호)

보안 패치는 서비스 이용이 적은 새벽이나 주말의 점검 시간에 시스템을 중단하고 적용하는 경우가 많다. 하지만 금융 거래와 온라인 서비스를 24시간 제공하는 기업은 패치를 위해 전체 시스템을 멈추는데 한계가 있다.

미토스 같은 프론티어 AI는 취약점을 발견하고 공격에 활용하는 데 걸리는 시간을 계속 줄이고 있다. 실제 공격에 쓰이거나 인터넷에 노출된 고위험 취약점은 정기 점검 일정까지 조치를 미루기도 어렵다. 취약점 악용 위험과 패치 장애 위험을 함께 관리해야 하는 이유다.

기업의 보안·인프라 관계자들은 서비스 중단을 줄이면서 긴급 패치를 적용하려면 ▲위험도에 따른 적용 순서 결정 ▲정식 패치 전 공격 경로 차단 ▲시험 환경 검증과 단계적 배포 ▲실시간 서비스 지표 확인과 복구 절차가 필요하다고 설명했다.

위험도 따라 순서 정하고 공격 경로부터 차단

전문가들이 짚은 첫 번째 방법은 ‘모든 장비를 같은 속도로 패치하기보다 자산의 위험도에 따라 적용 순서를 정하는 것’이다. 외부에서 접근할 수 있고 공격에 악용될 가능성이 큰 시스템은 조치를 앞당겨야 한다. 반면 패치가 핵심 거래나 데이터 처리에 영향을 줄 가능성이 크다면 적용 전 검증 범위를 넓혀야 한다.

한국마이크로소프트(이하 한국MS)는 윈도우와 윈도우 서버 패치 대상을 업무 중요도와 공격 노출도에 따라 여러 그룹으로 나누는 ‘단계적 배포 링’ 방식을 사용하고 있다.

시험 장비와 업무 영향이 작은 서버에 먼저 적용한 뒤 내부 업무 시스템과 일반 운영 서버, 인증·결제와 데이터베이스 같은 핵심 시스템으로 범위를 넓히는 방식이다. 인터넷에 직접 노출된 가상사설망(VPN)과 웹·메일 서버, 원격접속 장비는 별도의 우선순위로 관리한다.

한국MS 관계자는 “업무 중요도와 공격 노출도를 기준으로 단계적 배포 링을 구성하는 것이 바람직하다”며 “일정 관찰 시간 동안 이상이 없을 때 다음 그룹으로 확대하고 문제가 발견되면 배포를 중지한 뒤 원인을 확인해야 한다”고 말했다.

단계적 배포가 매번 긴 검증 기간을 의미하지는 않는다. 실제 공격에 악용 중인 취약점은 시험 대상과 관찰 시간을 줄여 조치를 앞당길 수 있다.

정식 패치를 곧바로 적용하기 어렵다면 취약점 공격 경로를 먼저 차단해 시간을 확보한다. 금융 플랫폼 토스(toss)를 운영하는 비바리퍼블리카는 이를 ‘선 차단, 후 배포’ 방식으로 설명했다. 비바리퍼블리카는 최전방에 있는 보안 시스템과 ‘애플리케이션 프로그래밍 인터페이스(API)’ 게이트웨이에서 취약점 공격 패턴을 차단한다. API 게이트웨이는 외부 요청의 인증과 접근권한, 트래픽을 관리하는 관문이다.

소프트웨어를 직접 수정하지 않고 웹방화벽이나 API 게이트웨이에서 공격 요청을 막는 방식을 ‘가상 패치’라고 한다. 정식 패치 전까지 공격 가능성을 낮출 수 있지만 소프트웨어 결함 자체를 없애지는 못한다. 차단 규칙이 정상 요청까지 걸러낼 수 있어 적용 뒤 오류율과 거래 성공률도 확인해야 한다.

비바리퍼블리카 관계자는 “패치로 서비스가 저하될 우려가 크다면 보안 조직이 우회 방어책으로 시간을 확보하고 개발 조직이 충분히 검증한 뒤 배포한다”고 설명했다.

시험 환경에서 검증하고 일부 시스템부터 적용

패치가 준비되면 운영 시스템 전체에 바로 적용하지 않고 별도의 환경에서 기존 서비스와 충돌하는지를 확인하는 과정이 필요하다.

카카오뱅크는 운영 환경과 분리된 검증 환경에서 미리 마련한 시나리오에 따라 패치를 시험하고 있다. 패치 대상 시스템뿐 아니라 연결된 시스템과 서비스에 미치는 영향도 함께 확인한다.

카카오뱅크 관계자는 “사전 테스트를 통한 철저한 리스크 검증과 적용 이후 실시간 모니터링에 기반한 최종 안정성 검증에 가장 중점을 두고 있다”고 설명했다.

반복적인 배포와 점검에는 자동화를 활용하지만 패치 적용 여부와 이상 징후에 대한 최종 판단은 담당자가 맡는다. 자동화는 같은 절차를 일관되게 수행하는 데 유리하지만 서비스 영향과 남은 위험까지 대신 판단하기는 어렵기 때문이다.

시험을 통과한 패치도 일부 서버와 이용자에게 먼저 적용한다. 단계적 배포의 대표적인 방식으로는 롤링과 블루·그린, 카나리 배포가 있다.

롤링(Rolling) 배포는 여러 서버를 한 대씩 순서대로 교체한다. 블루·그린(Blue-Green) 배포는 기존 환경과 패치를 적용한 새 환경을 함께 운영한 뒤 이용자 요청을 새 환경으로 전환한다. 카나리(Canary) 배포는 일부 서버나 소수 이용자에게 먼저 적용하고 이상이 없을 때 범위를 넓히는 방식이다.

비바리퍼블리카는 이 중에 카나리 배포를 이용해 패치 적용 트래픽을 1%, 5%, 25%처럼 단계적으로 확대하고 있다. 한 번에 전체 시스템을 바꾸지 않고 실제 거래에 미치는 영향을 확인하기 위함이다.

이중화로 트래픽 우회하고 재부팅은 순차 진행

패치 대상 서버를 서비스에서 잠시 제외하더라도 다른 서버가 이용자 요청을 처리할 수 있어야 전체 중단을 피할 수 있다. 이를 위해서는 같은 기능을 수행하는 서버를 여러 대 두는 이중화 구조가 필요하다.

카카오뱅크는 이중화된 환경에서 패치 대상 서버의 트래픽을 다른 서버로 우회한 뒤 순차적으로 조치한다.

비바리퍼블리카는 두 데이터센터를 동시에 가동하는 ‘액티브·액티브(Active-Active) 구조’를 활용한다. 한쪽 데이터센터에서 문제가 발생하면 다른 데이터센터로 요청을 전환한다. 패치 적용 비율을 조정하고 문제가 발생한 버전을 서비스에서 제외할 수 있다는 설명이다.

한국MS도 이중화된 서버를 로드밸런서에서 한 대씩 제외한 뒤 패치와 재부팅, 상태 확인을 마치고 다시 투입하는 방식을 제시한다. 로드밸런서는 여러 서버에 이용자 요청을 나눠 보내는 장치다.

일부 보안 업데이트는 재부팅 없이 적용하는 핫패치(Hotpatch)를 사용할 수 있다. 다만 모든 운영체제와 업데이트를 지원하지는 않는다. 닷넷(.NET)과 드라이버·펌웨어, 기준선 업데이트 등은 재부팅이 필요할 수 있다.

한국MS 관계자는 “핫패치는 장애 가능성을 없애는 기술이 아니라 재부팅 부담을 줄이는 기술”이라며 “단계적 배포와 모니터링은 필요하다”고 설명했다.

서비스 지표로 확대·복구 결정

패치 파일이 설치됐다는 것만으로 작업이 끝나지는 않는다. 패치 뒤에도 서비스가 정상적으로 작동하는지 확인해야 하기 때문이다.

한국MS는 설치와 재부팅 성공 여부와 함께 중앙처리장치(CPU), 메모리, 디스크, 네트워크 사용량을 확인해야 한다고 설명했다. 서비스 오류율과 응답시간, 애플리케이션·보안 로그, 사용자 장애 신고도 다음 배포 단계로 넘어갈지를 판단하는 기준이다.

특히 금융 서비스는 거래 성공률과 처리 지연이 중요하다. 비바리퍼블리카는 패치를 적용한 서버의 오류율이 높아지거나 거래 처리 시간이 늘어나면 배포를 중단한다. 핵심 기능 성공률이 떨어질 때도 이전 상태로 되돌린다.

비바리퍼블리카 관계자는 “확대나 롤백 여부는 실시간 데이터 지표로 결정한다”며 “일정 시간 동안 이상 징후가 없고 취약점 차단이 확인되면 다음 단계로 확대한다”고 설명했다.

카카오뱅크는 패치 전에 롤백 기준과 복구 계획을 마련한다. 적용 뒤 이상이 나타나면 서비스 영향도와 장애 범위를 판단해 검증된 이전 버전으로 복구한다.

패치 대상에 따라 복구 방법은 달라진다. 네이버클라우드의 경우, 애플리케이션 패치는 설정한 배포 범위 안에서 이전 버전으로 롤백할 수 있다고 설명했다. 운영체제와 커널 패치는 기본적으로 자동으로 롤백이 되지 않는다. 사전에 만든 서버 이미지와 스냅샷, 백업을 이용하거나 서버를 교체해야 한다.

네이버클라우드에 따르면, 데이터베이스 구조나 데이터 변환을 수반한 변경은 이전 상태로 되돌리기가 어렵다. 애플리케이션만 이전 버전으로 교체하더라도 새로운 구조에 저장된 데이터는 그대로 남을 수 있다. 따라서 데이터 변경이 포함된 패치는 백업과 복구 절차를 별도로 마련해야 한다.

한국MS 관계자는 “패치 관리는 단순한 설치 작업이 아니라 자산과 취약점, 배포 상태, 서비스 품질을 함께 보는 운영 위험 관리 절차”라고 강조했다.

글. 바이라인네트워크
<곽중희 기자>god8889@byline.network