[EOS] 보안시스템 EOS에 따른 대응방법

※ 블로그 운영자의 개인적인 의견입니다. 팩트와 글의 내용이 다를 수 있습니다.

서론

보안시스템의 서비스 또는 운영체제 EOS에 따른 대응 방안을 소개하고자 한다. EOS는 End Of Service로 더 이상 제조업체에서 더 이상 서비스를 지원하지 않겠다는 뜻이다. EOS(End Of Sales), EOL(End Of Life) 등 다양한 용어로 쓰고 있지만, 독자가 느끼기에는 대부분 EOS(End Of Service)로 통일해서 사용하고 있는 것 같다.

평소 EOS는 업무 상 굉장히 자주 듣는 단어이지만 독자에게는 해당사항이 없는 줄 알았다. 그러나 독자에게도 EOS에 따른 대응 요청사항들이 들어왔다. 따라서 독자가 느낀 EOS에 대해 어떤 위험이 있고 어떻게 대응해야하는지 경험을 공유하고자 한다.

 

Part 1. EOS 형태

독자가 느끼기에 EOS는 지원종료와 같다. 더 이상 제품군에 대한 서비스를 지원하지 않는 다는 내용이다. 보안시스템의 경우 보안 솔루션이 될 수도 있고, 보안시스템의 구성하고 있는 OS 또는 DBMS가 될 수 있다. (독자가 느끼기엔 2가지가 대부분이었음)

1. 제품군 지원 종료

2. OS 지원 종료

3. DBMS 지원 종료

 

Part 2. 형태에 따른 대응 방법

제품군 지원 종료

제품군 지원 종료 시, 제품을 업데이트해야한다. 업데이트는 기존 환경에서 업데이트될 수 있으며 새로운 환경을 요구할 수 도 있다. 해당 솔루션으로만 중앙집중배포가 가능하지 않을 수 있다는 얘기이다. 또한 구 버전과 신 버전의 마이그레이션이 필요하며, 구축 및 추가 기능들에 대한 업그레이드 비용이 발생할 것이다. 담당자는 EOS의 만료기간을 주기적으로 확인하여 연간투자계획에 반영해야할 것이다. 단점만 있는 것은 아니다. 새로운 기능들이 추가로인해 기존에 조직에서 어려움을 겪던 부분들이 해결될 수 있다. 또한 기존 서비스 에러사항들에 대해서도 조치할 수 있다.

 

OS 지원 종료

독자의 회사는 윈도우, 리눅스, 유닉스 서버를 운영하고 있다. 최근 CentOS Linux 7이 EOL 되면서 많은 이슈가 있었다. 무료버전이기에 많은 기업들이 채택하고 있는 뜻하다. OS를 변경하는 작업에서 가장 중요한 것은 호환성이다. CentOS와 가장 유사한 환경을 제공하며 무료인 OS는 RockyOS이다. 그래서 많은 기업들이 RockyOS로 갈아타는 것을 고려하고 있다.

OS 변경 작업에서 가장 중요한 것은 호환성이다. 다시 말해서 OS만 바뀐상태에서 기존 서비스가 정상작동한다면 전혀 문제가 없다는 뜻이다. 보안담당자 입장에서는 버전의 호환성 이슈, 마이그레이션 작업, 백업 및 복구작업에 대해 확인하면 된다. 

 

DBMS 지원 종료

가장 많이 발생하는 문제이다. 독자의 조직에서는 정말 많은 DBMS를 운영하고 있는데, DBMS마다 버전이 다르다. EOS되어서도 버전 업을 못하고 있는 것 또한 문제일 것이다. 실제 운영되고 있는 서비스의 경우 24시간 가용성을 확보해야 하는데 타 서비스와 통신이 많은 서비스의 경우, 100% 동일한 환경에서 TEST하는 것이 불가능에 가깝다. 작업은 버전 호환성 이슈, 마이그레이션 작업, 백업 및 복구작업 등이 대부분일 것이다. 하지만 OS보다는 고려해야할 사항들이 많다는 것은 사실이다.

 

Part 3. EOS에 따른 보안 위험 사항

제공 받는 서비스마다 다르겠지만, EOS가 된다면 더 이상 업체로부터 서비스 지원을 받지 못한다. 서비스에 이슈가 발생해도 더 이상 관여하지 않겠다는 뜻이다.

1. 장애 발생에 대한 대응
2. 서비스 버그에 대한 패치 중단
3. 보안 취약점 대응에 대한 패치 중단

장애 발생 시 많은 장애 대응 및 백업에 대한 복구 등 다양한 작업들이 신속하게 이루어 져야한다. 이러한 작업들은 서비스 운영을 아무리 많이 해보았다 하더라도 제조 업체의 서비스 지원 담당자가 제일 잘 알것이다. 즉 장애에 대한 신속 대응이 불가능하며 장애에 따른 기업 이미지 손상, 장애 대응 시간에 손해비용이 발생할 것이다.

서비스 버그 발생 시, 보안담당자는 서비스 버그로부터 대응할 수 없다. 보안담당자는 완벽해야 하는 이미지를 비추어야 하는데, 서비스 이용자들로부터 신뢰성을 잃을 수 있다.(독자의 개인적인 생각이지만 보안이란 업무 자체가 남들을 귀찮게 하는 업무다 보니 항상 욕먹는 위치에 있는 뜻하다. 그래서 틈이 보이지 않도록 누구보다 완벽해야 한다.)

보안 취약점 발생 시, 가장 문제가 된다. 예를 들어 해당 서비스가 65335라는 포트를 사용하는데 해당 포트에서 취약점이 나왔다고 한다면 해당 취약점을 막는 이상 대응할 방법이 없다. (포트는 막기라도할 수 있지... 특정 모듈에서 취약점이 나왔다고 한다면 답이 없다.) 차선책은 언제나 보안패치이지만 차선택을 선택할 수 없기에 위험을 수용하며 다른 대응방안을 수립해야 한다. 해당 사항들이 보안 컴플라이언스에 충돌된다면 대응이 더욱 시급해질 것이다.

 

Part 4. 업그레이드 작업 계획서

EOS에 따른 업그레이드 계획서

조직에서는 업그레이드에 대한 위험을 안고 가야하기에 업그레이드 계획서를 작성해야 한다. 업그레이드 계획서에는 아래 내용들이 포함되어야 한다.

1. 작업명
2. 작업 대상
3. 작업 기간
4. 작업 담당자
5. 작업 상세내용
6. 복구 계획
7. 정상 여부 확인 및 모니터링 계획

대부분의 보고서와 같이 6하원칙을 토대로 작성되어야 한다. 그 중 보안담당자가 신중히 확인해야 할 사항들은 작업 상세내용 및 복구 계획이다. 작업 상세내용에는 어떤 명령어를 입력하여 작업이 진행되는지, 작업 도중 서비스 Down-Time 발생 시 어떻게 대응 할 수 있는지가 포함되어야 한다. 서버가 이중화되어 있다면, Active-Active 인지 Active-Standby인지에 따라 서비스의 Down-Time이 발생하지 않는지 상세하게 살펴보아야 한다. 당연한 얘기지만 Down-Time은 발생하지 않는 것이 좋다.

복구 계획은 업그레이드 도중 문제 발생 시 어떻게 원위치 시키는지 이다. 보통 백업파일을 토대로 복구하는데, 백업파일로 복구가 불가능 할 수도 있다. 작업 내용과 마찬가지로 서비스 구성도에 따라 이중화가 정상적으로 되는지 등 구체적인 검토가 필요하다.

 

요약 

1. EOS 대응은 보안담당자도 해야하며, 서비스의 EOS 항목이 어떤 것인지 명확하게 확인할 필요가 있다.

2. 주기적으로 EOS가 되는 서비스가 어떤 것이 있는지 확인하며, 필요 시 투자계획에 반영해야 한다.

3 업그레이드 계획서를 작성하며 서비스 인프라에 따른 Down-Time 발생을 최소화해야한다.