업데이트 또는 업데이트하지 않으려면?

지금 일하고있는 곳에서 일을 시작한 이래로 나는 시스템 업데이트와 관련하여 상사와 동료들과 끝없이 싸우고 있습니다.

물론 모든 업데이트 (펌웨어, OS 또는 응용 프로그램)가 나 오자마자 부주의하게 적용해서는 안된다는 데 전적으로 동의하지만 , 공급 업체가 릴리스 한 경우에는 최소한 어떤 이유 가있을 것이라고 확신 합니다. 가장 일반적인 이유는 일반적으로 버그를 수정하는 것입니다. 아마도 지금은 겪지 않을 수도 있지만을 계속하지 않으면 곧 겪을 수도 있습니다.

보안 수정의 경우 특히 그렇습니다. 예를 들어, 이미 몇 달 동안 사용 가능한 패치를 적용한 사람이 있다면 악명 높은 SQL Slammer웜은 무해했을 것입니다.

저는 배포하기 전에 업데이트를 테스트하고 평가합니다. 그러나 시스템 관리에 대한 "손상되지 않으면 손대지 마십시오"접근 방식에 강력하게 동의하지 않으며 프로덕션 Windows 2003 SP1 또는 ESX 3.5 업데이트 2 시스템을 찾을 때 진정으로 아파요 . "작동 중입니다. 우리는 그것을 중단하고 싶지 않습니다".

이것에 대해 어떻게 생각하십니까? 당신의 정책
은 무엇입니까 ? 회사 정책 이 자신의 정책과 맞지 않으면 어떻게됩니까?

펌웨어 업데이트 (BIOS, 스토리지 등)는 어떻습니까?
주요 OS 업데이트 (서비스 팩)는 어떻습니까?
사소한 OS 업데이트는 어떻습니까?
응용 프로그램 업데이트는 어떻습니까?

클라이언트 패치 관리가 일반적으로 더 쉽고 서버를 처리하는 잘 알려진 도구와 모범 사례가 있기 때문에 서버 업데이트에 관심이 있습니다.

패치 전략을 결정할 때 보안 및 민첩성은 안정성 및 가동 시간과 균형을 이루어야합니다. 이에 대한 푸시 백 접근 방식은 '알겠습니다.하지만 이제 이러한 서버가 손상되어 데이터를 도난 당하거나 서버가 작동하지 않을 위험이 있음'을 알아야합니다. '하지만, 이것이이 시스템에 대한 공급 업체의 지원과이 시스템이 새로운 시스템과 상호 작용할 수있는 미래의 능력에 영향을 준다는 것을 알아야합니다.'

장기적인 '파산하지 말고 업데이트하지 마십시오'라는 사고 방식에 대비하여 다음을 분명히해야합니다.

• 패치되지 않은 레거시 시스템을 최신 시스템 으로 이전하는 것은 시간이 지남에 따라 시스템을 점진적으로 업데이트하는 것보다 훨씬 비싸고 고통스러운 프로세스입니다.
• 숙련되고 숙련 된 IT 직원은 IT 시스템을 지속적으로 발전시키는 새로운 기술과 회사를 적극적으로 찾습니다. 시스템이 정체되어 작업하기가 어려워 져 회사의 참여도가 높고 창의적인 IT 직원을 잃을 경우 매출, 비용 손실 및 지식 손실이 발생합니다. 그런 다음 남은 것은 '생명'입니다.

위의 사항을 심각하게 받아들이도록 설득하는 데 도움이되고 행운을 빕니다. 항상 그렇듯이 위험을 관리한다는 사실을 입증하는 문서 추적을 설정하십시오.

이것은 끝없는 논쟁이며 합리적인 사람들은 동의하지 않을 것입니다. 사용자 PC에 대해 이야기하고 있다면 업데이트해야한다는 데 동의합니다. 서버에 대해 이야기하는 경우 인터넷에 연결된 서버와 그렇지 않은 서버에 대한 별도의 정책을 고려하십시오. 서버에 대해서는 모르지만 내 환경에서는 서버의 10 %가 포트가 인터넷에 연결되어있을 수 있습니다. 이러한 인터넷 연결 서버는 보안 패치와 관련하여 가장 높은 우선 순위를 갖습니다. 인터넷을 사용하지 않는 서버는 우선 순위가 낮습니다.

보안 전문가들은 해커가 네트워크에 침입하면 패치되지 않은 서버가 악의적 인 공격이 와일드 파이어와 같은 네트워크를 통해 침입 할 수 있기 때문에이 방법이 문제가된다고 주장합니다. 그래도 인터넷에 연결된 서버를 단단히 고정하고 방화벽이 꼭 필요한 포트만 열도록 방화벽을 올바르게 구성하면이 방법이 효과가 있으며 패치를 두려워하는 관리자를 달래는 데 종종 사용될 수 있다고 생각합니다.

패치를 위해 Windows Update에만 의존하는 경우 (실행중인 OS는 언급하지 않았지만 대부분 Windows 사용자이므로 이것이 내 참조입니다) 매월 릴리스되는 실제 핫픽스를 살펴보십시오. . 서버에 Windows Update를 실행하면 50 개 이상의 패치가 필요하다는 메시지가 표시되지만 패치를 스크롤하여 각 패치를 조사하면 패치중인 항목의 90 %가 보안이 아님을 알 수 있습니다 관련이 있지만 해당 상자에서 실행되지 않는 서비스에 영향을 미치는 버그를 수정합니다. 패치 관리 시스템을 사용하는 대규모 환경에서는 릴리스 된 모든 항목을 검토하는 것이 일반적이며 Microsoft가 릴리스하는 것의 약 10 %에 해당하는 것이 절대적으로 필요한 것에 귀찮게합니다.

나의 주장은 "패치 또는 패치하지 않기"에 대한이 논쟁은 실제로 이것이 거대한 회색 영역 일 때 한쪽 또는 다른 쪽이어야한다고 제안한다.

서버에 대해서만 이야기 할 수 있지만 매년 4 개의 미리 결정된 날짜와 발표 된 날짜에 '분기 별 업데이트'체제가 있습니다. 업데이트 요청을 모아서 참조 환경에 적용하고 한 달 동안 실행하여 안정성을 테스트하고 롤아웃하는 경우 다음 n 일 / 주 동안. 이 외에도 긴급 업데이트 정책을 적용하여 심각도가 이러한 경우 하루 또는 이틀 내에 긴급 업데이트를 참조, 테스트 및 롤아웃 할 수있는 기능을 제공합니다. 이는 마지막에 2/3 회만 사용되었지만 4 년 정도

이 두 가지 접근 방식은 서버가 합리적이지만 최신이 아닌 최신 상태를 유지하도록하며 업데이트는 공급 업체가 아닌 주제별 전문가 (예 : 펌웨어, 드라이버, OS, 앱 스태프)에 의해 이루어 지지만 다음과 같은 경우 빠른 수정이 가능합니다. 필요합니다. 물론 전체 비즈니스 (<10 서버 변형) 및 테스트 할 수있는 최신의 참조 플랫폼에 대해 서로 다른 하드웨어 모델이 거의없는 것이 행운입니다.

나는 "ASAP 패치 적용, 우리는 그들이 우리가 일한 것을 깨뜨려도 상관 없다-우리는 그 다음에 되돌릴 것이다"에서 "2 주가 지나도 아무것도 적용되지 않는다"에서 연속체에 걸쳐 정책을 가지고있는 다른 회사들에서 일했다. 테스트 중입니다. " 회사가 트레이드 오프를 이해하는 한 두 극단 (및 그 사이의 포인트)은 괜찮습니다 .

이것이 중요한 요점입니다.이 질문에 대한 옳고 그름의 특정 대답은 없습니다. 특정 환경에서 안정성과 안전 또는 기능의 균형을 유지하는 문제입니다 . 관리 체인이 테스트를 위해 패치를 지연 시키면 맬웨어에 더욱 취약해질 수 있음을 이해하면 문제가 없습니다. 마찬가지로 패치를 사용할 수있게되는 즉시 적용하면 작동하지 않거나 특정 시스템 구성이 손상 될 수 있다는 것도 이해합니다. 이러한 장단점을 이해하지 못하면 문제가 발생합니다.

내 견해는 최고의 코스가 두 극단의 중간에 거의 치열하다는 것입니다. 예를 들어 입증 할만한 이유가 없다면 프로세스에서 작업 시스템을 손상시킬 수있는 이유가 없다면 왜 ESX를 업그레이드해야합니까? 공개적으로 직면 한 경우 취약 할 수 있지만 네트워크 외부에서 직접 액세스 할 수있는 방법이 없어야 할 위험이 있습니까? 어떤 버그가 있습니까 또는 실제로 당신을 제시하는 기능이 부족 이유 업그레이드?

그것을 위해 업그레이드하는 것은 실제로 당신이 제안하고있는 것이지만 ( "당신 은 곧 경험할 수 있습니다"), 당신이 아니라고 주장하더라도, 터무니없고 위험한 여행의 길입니다. 이론적으로 가능한 일부 이유와 달리 실제 이유를 제시 할 수 없다면 업그레이드에 반대하는 다른 사람들을 설득하지 않을 것입니다.

업그레이드를 수행해야하는 실질적인 이유가 있다고 생각되면 장단점을 모두 문서화해야하며 항상 상위 장단점이 있어야합니다. 저항이 적어야한다는 것을 올바르게 기록했습니다. 설득력있는 주장을 할 수 없다면, 앉아서 그 사실을 진지하게 생각해보십시오.

편집하다

소프트웨어 또는 OS 업그레이드 수행과 비교할 때 필요한 보안 패치와 안정성 패치를 적용하는 데 큰 차이가 있음을 분명히해야한다고 생각했습니다. 첫 번째는 적절한 테스트 후 구현합니다. 후자는 실제 혜택이있는 경우에만 수행합니다.

보안 업데이트는 준비 서버로 전송 된 다음 문제가 발생하지 않았다는 사실을 보여준 후에 제작됩니다. 실제 깜빡이는 비상 상황이 아닌 한 (내가 몇 번 쳤다 :(),이 경우 PRODUCTION NOW.) 준비에 시간을 보낸 후 필요한 경우에만 다른 업데이트.

가장 먼저해야 할 일은 업데이트를 심각도별로 "분류"하고 분류에 따라 패치 일정을 세우는 것입니다. 제로 데이 보안 픽스를 즉시 적용해야한다는 것은 의심 할 여지가 없습니다. 주의 깊게 평가 한 후 서비스 팩이 대기 할 수 있습니다.