소프트웨어 배포와 패치 적용은 조직의 IT 팀에 부여된 가장 중요한 업무 중 두 가지입니다.
이러한 작업을 처리하기 위해 고안된 다양한 도구가 있으며, 이는 일반적으로 ‘ ’ 소프트웨어 관리 범주에 속합니다.
하지만 종종 간과되는 점은, IT 부서가 해당 업무를 위해 어떤 도구를 선택하든 간에, 조직이 소프트웨어 환경을 진정으로 통제하기 위해서는 먼저 프로세스 및 정책상의 문제들을 해결해야 한다는 사실입니다.
게다가 많은 조직들은 2000s년대 초반 이후로 소프트웨어 관리 방식을 바꾸지 않고 있습니다. 이 블로그에서는 이러한 프로세스 관련 고려 사항 중 몇 가지를 지적하고, 그 중요성을 설명합니다.
체크리스트: 알아두어야 할 현대적인 소프트웨어 관리 관행
소프트웨어 배포와 패치 적용을 중앙 집중식으로 관리하는 것이 가장 효과적입니다.
제 경험에 비추어 볼 때, 소프트웨어 관리를 위해 분산형 모델을 사용하는 기업들은 중앙 집중형 모델을 사용하는 기업들에 비해 보안 관행이 훨씬 더 열악합니다.
여기서 ‘중앙 집중식’이란, 조직 내 지원 인력은 분산되어 있을 수 있지만, 어떤 소프트웨어와 소프트웨어 업데이트를 언제 설치할지 결정하는 단일한 중앙 권한이 존재한다는 것을 의미합니다. 분산된 지원 팀들은 모두 그 리듬에 맞춰 움직입니다.
중앙화는 테스트 및 패치 적용 속도를 높여줍니다
소프트웨어 관리에서 가장 중요한 측면 중 하나는 테스트 및 패치 적용 속도입니다. 중앙 집중형 모델로 전환할 때는 단계적으로 도입하는 것이 좋습니다. 본격적으로 운영 환경에 배포하기 전에 몇 차례의 테스트 단계를 거쳐야 합니다. '몇 개'는 두세 개를 뜻하는 것이지, 20개를 뜻하는 게 아닙니다!
요점은, 엔드포인트 기기가 너무 오랫동안 취약한 상태로 방치되어서는 안 되므로, 해당 업데이트를 가능한 한 빨리 배포해야 한다는 것입니다. 일반적으로 현실적인 목표 기간은 7-15 일이며, 업데이트의 중요도에 따라 이보다 짧아질 수도 있습니다.
이것이 바로 소프트웨어 관리의 정책적 측면입니다. 가장 중요한 패치에 대한 서비스 수준 계약(SLA)을 정의하십시오. 숫자를 가능한 한 낮게 유지하세요. 지난 20 년 동안 해온 일을 바탕으로 수치를 산정해서는 안 됩니다. 목표를 세울 때는 과감하게 설정하세요.
30 일은 꽤 긴 시간입니다
어떤 회사에 들어갔을 때, 해당 회사의 패치 주기가 30 일보다 길다면, 첫 번째 단계는 30 일 이내에 이러한 업데이트를 배포하고 모든 기기에 설치하는 것입니다. 그 정도보다는 나쁘지 않을 겁니다.
이러한 업데이트가 출시되면 악의적인 사용자들도 이를 확인하게 된다는 점을 이해해야 합니다. 여러분의 시스템에 침투하려는 사람들은 문서를 읽을 수 있으며, 어떤 부분이 패치되는지, 그리고 그 이유가 무엇인지 파악할 수 있습니다. 시간은 이미 촉박해졌으므로, 악용 코드가 개발되어 사용되기 전에 소프트웨어를 업데이트해야 합니다. 그래서 제가 30 일은 꽤 긴 시간이라고 말하는 겁니다.
물론, 운영 환경에 패치를 항상 즉시 적용하고 싶지는 않을 수도 있습니다. 어쩌면 애플리케이션 내부의 종속성 문제로 어려움을 겪고 계실 수도 있습니다. 예를 들어, .Net 패치가 사용자가 직접 개발한 맞춤형 애플리케이션 중 하나와 제대로 호환되지 않을 수도 있습니다. 이런 일들은 어차피 일어날 거예요.
일반적으로 이러한 충돌 여부를 확인할 수 있는 기간은 약 일주일 정도입니다. 그리고 궁극적으로는 그 30 일을 가능한 한 일주일에 가깝게 줄이는 것이 목표입니다. 그것이 목표가 되어야 합니다.
정확히 얼마나 심각한 상황인가요? “뒤늦은 패치”의 세계
지난 몇 년 동안 제가 놀라웠던 점은, 얼마나 많은 기업들이 자사가 아주 잘하고 있다거나 적어도 나쁘지 않다고 생각한다는 사실입니다. 그들은 스스로에게 “B+”를 매긴다.
하지만 이후 평가를 실시한 결과, 2007년으로 거슬러 올라가는 수천 개의 중요 패치가 발견되었습니다. 분명히 뭔가 제대로 작동하지 않는 것 같습니다. 대개는 도구와 프로세스의 조합입니다. 두 가지 모두 해결해야 합니다.
많은 기업에서 현재 사용하고 있는 ‘ ’ 패치 적용 방식( )은 2007 년이나 2010년 때와 다를 바가 없습니다. 하지만 그들이 활동하고 있는 환경은 변했습니다. 그들은 그 사실을 알고 있었든 몰랐든 간에, 10년 분량 이상의 누락된 패치가 쌓여 있습니다.
운영 체제에 대한 중요하고 필수적인 보안 업데이트부터 시작하는 것은 드문 일이 아닙니다. 이 업데이트들에는 모두 심각도 등급이 지정되어 있으므로, 이를 통해 운영 체제의 취약성 수준을 파악할 수 있습니다.
의 타사 애플리케이션 업데이트()와 관련된 심각도 등급도 있습니다. 여기에는 Adobe Acrobat(Adobe Flash의 지원 종료(EOL)에 대한 블로그 게시물 참조: ), Chrome 및 Firefox와 같은 웹 브라우저, Office365과 같은 생산성 앱 등이 포함됩니다.
“누락된 패치 적용”을 할 때는 가장 시급하고 중요한 업데이트부터 시작하십시오. 분산 환경에서는 이 방법이 비용 대비 가장 큰 효과를 얻을 수 있는 방법이지만, 거기서 멈추지 마세요.
소프트웨어 관리의 문제점을 기술적으로 파악하는 것은 쉽지만, 이를 해결하는 것은 쉽지 않다
소프트웨어 배포 및 패치 적용 방식에 존재하는 문제점을 파악하는 데는 그리 오랜 시간이 걸리지 않습니다. 하지만 이러한 격차를 해소할 정책과 절차에 대해 합의를 도출하는 과정은 시간이 오래 걸리고 논란을 불러일으킬 수 있다.
사람들은 특정 방식으로 일을 해오며 경력을 쌓아왔기 때문에, 대개 변화를 원하지 않습니다. 대부분의 경우, 사람들이 자신의 정책을 진지하게 평가하고 성찰하기 전까지는 그 정책이 존재하는 유일한 이유가 “우리가 항상 그렇게 해왔기 때문”이라는 사실조차 깨닫지 못합니다. 업데이트 후 시스템 재부팅과 관련해 가장 큰 반발을 겪을 가능성이 높은 부분 중 하나입니다.
이는 시스템 재부팅이 최종 사용자에게 영향을 미치기 때문입니다. 조직이 적절한 알림을 제공하면서 엔드포인트를 재부팅할 시점을 결정하는 데는 말 그대로 몇 달이 걸릴 수도 있습니다. 즉, 직원이 점심 먹으러 자리를 비운 때나 발표 도중, 혹은 중요한 문서를 작업하는 중에 재부팅이 이루어지지 않도록 해야 하기 때문입니다.
이 때문에 재부팅 정책을 철저히 이행하기 위해서는 강력한 경영진의 리더십이 필수적입니다. 특히 Windows 환경에서는 시스템이나 애플리케이션이 재부팅되기 전까지는 패치가 제대로 설치되지 않고, 취약점이 있는 코드가 교체되지 않기 때문입니다.
일부 조직에서는 재부팅을 최종 사용자의 판단에 맡기며, 재부팅이 필요하다는 알림도 제공하지 않습니다. 더 엄격한 정책이 시행된다면 최종 사용자들은 이에 적응할 것이다.
사용자들은 알림을 처음이나 두 번째 받았을 때 — 아마도 점심 시간 전쯤 — 재부팅을 하는 법을 배우게 될 것이며, 재부팅이 부적절한 시간에 강제로 이루어질 때까지 계속 “나중으로 미루기”를 클릭하는 일은 없을 것입니다.
고객사와 소프트웨어 배포 작업을 진행할 때, 우리가 가장 먼저 확인하는 사항 중 하나는 마지막 재부팅 시점입니다. 그리고 조직 내 시스템의 75 %가 재부팅을 기다리고 있는 경우가 종종 있습니다. 그럼, 방금 적용하신 패치들 말인데요? 전혀 그렇지 않아요.
소프트웨어 패치에 관한 모든 논의에는 위험 요소가 수반됩니다.
조직들이 패치를 신속하게 적용하지 않는 주된 이유는 무언가 문제가 생길까 봐 두려워하기 때문이다. 부사장이나 최고 경영진과 소프트웨어 업데이트에 대해 이야기를 나눌 때면, 매번 대화에서 위험 문제가 거론됩니다. “내 시스템이 45 일 동안 취약한 상태로 남아 있을 위험과, 30 일 만에 무언가를 배포했다가 애플리케이션이 오작동할 위험 중 어느 쪽이 더 클까요?” 그건 미지에 대한 두려움입니다. 사업 중단에 대한 두려움입니다.
테스트 계획과 지표가 있다면, 그러한 두려움을 줄일 수 있습니다. 비록 그 테스트 계획이 단순히 “이 업데이트를 여러 시스템에 배포한 다음, 문제가 발생하는지 확인해 보자”는 것일지라도. 하지만 무언가 고장 났는지 여부는 알 수 있어야 합니다. 해당 데이터는 이미 보유하고 있어야 하며, 누군가가 문제 신고를 접수해야만 확인할 수 있는 상황에 의존해서는 안 됩니다.
애플리케이션 소유자들이 패치의 안전성을 입증하는 확실한 데이터를 보유하고 있다면, 패치 주기를 30 일에서 15 일로 단축하겠다고 제안했을 때 더 기꺼이 동의할 것입니다.
Tanium이 의 타사 소프트웨어 관리를 어떻게 간소화하는지 알아보려면를 방문하시고, 와 ‘Tanium이 엔드포인트 소프트웨어 환경을 제어할 수 있게 해주는 9 가지 방법’도 꼭 확인해 보시기 바랍니다.
실제 작동 모습을 확인해 보실 준비가 되셨다면, 오늘 바로 데모에 등록해 보세요.
