SRE를 위한 시스템 설계와 구축

201

7

장

범위의 변화를 위한 설계

발표 내용이 유출되거나 공개적으로 알려져 공격이 가능해지거나 또는 취약점이 다른 곳에

서 사용된다면 일정이 바뀌게 된다. 이런 경우에는 가능한 빨리 패치를 진행해야 한다. 엠바

고가 무효화된 경우에는 매 단계의 실행 계획을 갖춰야 한다.

영향도가 심하지 않은 경우

취약점이나 변화가 외부 사용자가 직접 사용하는 서비스에 영향을 주지만 여러분의 조직

이 이런 서비스를 거의 보유하고 있지 않다면 전체 인프라스트럭처를 서둘러 패치할 필요는

없을 것이다. 일단 영향을 받는 부분만 패치하고 시스템의 나머지 부분은 천천히 패치해도

된다.

서드파티에 의존하고 있는 경우

대부분의 조직은 취약점에 대한 패치가 적용된 패키지와 이미지의 배포를 서드파티에 의존

하거나 소프트웨어와 하드웨어 전달에 인프라스트럭처 변화가 필요한 경우가 있다. 만일

OS

용 패치가 없거나 필요한 하드웨어의 재고가 없이 이월된 경우라면 딱히 여러분이 할 수 있

는 일이 없다. 이런 경우에는 원래 의도했던 것보다 늦게 변화를 적용할 수밖에 없을 것이다.

7.6

예시: 범위의 증가 - 하트블리드

2011

년 겨울,

OpenSSL

에

SSL

/

TLS

의 하트비트

heartbeat

기능에 대한 지원이 추가되었다. 이때

서버나 클라이언트가 다른 서버나 클라이언트의 비공개 메모리 중

64KB

에 접근할 수 있는 버

그(

https

://

xkcd

.

com

/

1354

)가 함께 발생한 것을 미처 인지하지 못했다.

2014

년

4

월 구글

러 중 한 명인 닐 메타

Neel

Mehta

와 (사이버 ...