2019.04.16

협정세계시(UTC)가 윈도우 보안에서 중요한 이유

Susan Bradley | CSO
시간대는 비교적 새로운 개념이다. 영국에서 열차와 일정을 조율하기 위해 '열차시'라는 개념을 만들었는데, 각 마을과 역마다 다른 현지 시간으로 인한 혼란을 극복하기 위해서였다. 역을 드나드는 열차의 일정 문제와 사고를 줄이기 위해서도 필요했다. 여행의 범위와 종류가 늘어나면서 표준화의 필요에 따라 시간대가 생겼다. 여기에 기술이 추가되면서 현지 시간의 필요성이라는 개념으로 발전했다.



과거에는 서버 로깅을 서버가 위치한 현지 시간으로 설정했다. 이는 특히 로컬 컴퓨터에 대한 이벤트 상호 연결을 일관성 있게 해 줬다. 그러다가 인터넷이 탄생했고 서버는 클라우드와 데이터센터로 옮아갔다. 그러다 보니 이제는 로깅을 현지 시간으로 설정하는 것의 의미가 사라졌다. 게다가 업무지원센터와 분산 조직이 생기고 전사적으로 상호 연결을 처리하므로 로깅을 협정세계시(UTC)로 바꾸는 움직임이 나타나고 있다.

UTC의 정의와 보안에 중요한 이유
UTC는 세계의 시간 기준 중심지가 시간 척도를 동기화 상태로 유지할 수 있도록 도와주는 24시간 단위 시간 표준이다. UTC의 기준이 되는 세계 시(UT1)는 지구의 자전 속도를 이용해 시간을 측정한다. 만일 네트워크 전반에 걸쳐 시간이 제대로 동기화되지 않으면 보안 업데이트, 인증, 디지털/컴퓨터 포렌식 수사에 지장을 줄 수 있다. 로깅 시간을 UTC로 옮기면 네트워크 전체를 동기화 상태로 유지하는 데 도움이 된다.

모든 의사 결정이 그렇듯 해당 기업에 의미가 있는 것을 판단해야 한다. 작은 회사여서 관리자와 사용자 모두가 같은 시간대에 있다면 해당 시간대로 로깅하는 것이 더 적절하다. 반면 다양한 시간대의 로깅 기록을 분석하기 위해 중앙 위치 한 곳으로 모으는 경우라면, 교차 분석을 위해 UTC를 선택하는 것이 합리적이다. 로깅 및 방화벽 업체에 문의해 보는 것도 좋다.

애플리케이션에서 시간대를 선택해 주는 경우도 많다. 따라서 어떤 시간대가 선택되었는지 미리 알아둬야 한다. 예를 들어, 마이크로소프트의 웹 서버 IIS(Internet Information Services)는 다년간 UTC 시간을 기본 선택하곤 했다. KB271196에서 언급된 것처럼, IIS에서 사용하는 확장 로그 파일 형식은 필립 할람 베이커와 브라이언 벨렌도르프에 의해 W3C 워킹 드래프트 WD- logfile-960323 사양에 정의됐다. 이에 따르면 날짜와 시간 파일이 항상 그리니치 평균시(GMT)가 되도록 정의했다. GMT는 UTC와 똑같이 현재 시간을 공유한다. 현지 시간대를 원하는 경우에는 조정해야 했다.

마이크로소프트의 클라우드 플랫폼 애저의 현재 시스템 기준은 UTC이지만 언제나 그랬던 것은 아니다. 2009년에 애저의 로깅 시간을 태평양 표준시에서 UTC로 옮기기로 했다. 애저와 윈도우 디펜더 고급 위협 방지(ATP) 포털은 로깅 및 추적 정보에 UTC를 사용한다. 로컬 컴퓨터는 현지 시간대에 있지만 APT 포털의 로깅은 항상 UTC이다. 단, 메뉴의 지구 아이콘을 클릭해 컴퓨터의 현지 시간대와 UTC 간에 쉽게 전환할 수 있다.
 
윈도우 디펜더 ATP의 시간대 설정

포렌식에서는 컴퓨터가 위치한 시간대를 파악하기 위해 레지스트리를 사용하는 경우가 많다. 컴퓨터가 어떤 시간대로 설정되었는지 파악하려면 HKEY_LOCAL_MACHINE\ControlSet001\Control\TimeZoneInformation을 확인하거나 켜져 있는 컴퓨터에서 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation을 확인하면 된다. 그러면 <화면 *>처럼 컴퓨터의 시간대를 확인할 수 있다.
 
윈도우 레지스트리키에서 시간대를 확인할 수 있다.

시간과 애저, 그리고 특히 SQL을 다룰 때는 GETDATESYSDATETIME 같은 기능을 사용하는 대신 GETUTCDATESYSUTCDATETIME을 고려하는 것이 좋다. 구형 SQL 애플리케이션은 클라우드 플랫폼을 염두에 두지 않고 현지 시간을 사용해 작성된 경우가 많다. 애플리케이션을 클라우드로 옮기기 전에 UTC 시간으로 전환하는 것을 감당할 수 있는지 확인해야 한다.

마지막으로, 파워셸을 이용해 컴퓨터의 정확한 시간대를 파악할 수 있으며 일련의 원격 컴퓨터로부터 시간대를 파악할 수 있다. Get-TimeZone 명령어를 이용하면 컴퓨터의 시간대에 반응한다. 서버 목록을 붙여 여러 시스템의 시간대를 파악할 수 있다.
 
파워셸로 시간대 정의하기

정리하면, 애플리케이션, 로깅 등 시간에 민감한 모든 것을 살펴보고 UTC 시간으로 옮길 수 있는지, 아니면 현지 시간에서 UTC 시간으로 변환하기 쉬운지 판단해야 한다. 어떤 것이 기업에 더 적합하고 더 좋은 정보를 제공해 주는지도 봐야한다. 기본적으로 추가하는 클라우드 서비스가 늘어날수록, 네트워크 전체의 로깅 시간을 UTC로 옮기는 것이 이벤트 상호 연결을 위한 가장 합리적인 선택이다. ciokr@idg.co.kr


2019.04.16

협정세계시(UTC)가 윈도우 보안에서 중요한 이유

Susan Bradley | CSO
시간대는 비교적 새로운 개념이다. 영국에서 열차와 일정을 조율하기 위해 '열차시'라는 개념을 만들었는데, 각 마을과 역마다 다른 현지 시간으로 인한 혼란을 극복하기 위해서였다. 역을 드나드는 열차의 일정 문제와 사고를 줄이기 위해서도 필요했다. 여행의 범위와 종류가 늘어나면서 표준화의 필요에 따라 시간대가 생겼다. 여기에 기술이 추가되면서 현지 시간의 필요성이라는 개념으로 발전했다.



과거에는 서버 로깅을 서버가 위치한 현지 시간으로 설정했다. 이는 특히 로컬 컴퓨터에 대한 이벤트 상호 연결을 일관성 있게 해 줬다. 그러다가 인터넷이 탄생했고 서버는 클라우드와 데이터센터로 옮아갔다. 그러다 보니 이제는 로깅을 현지 시간으로 설정하는 것의 의미가 사라졌다. 게다가 업무지원센터와 분산 조직이 생기고 전사적으로 상호 연결을 처리하므로 로깅을 협정세계시(UTC)로 바꾸는 움직임이 나타나고 있다.

UTC의 정의와 보안에 중요한 이유
UTC는 세계의 시간 기준 중심지가 시간 척도를 동기화 상태로 유지할 수 있도록 도와주는 24시간 단위 시간 표준이다. UTC의 기준이 되는 세계 시(UT1)는 지구의 자전 속도를 이용해 시간을 측정한다. 만일 네트워크 전반에 걸쳐 시간이 제대로 동기화되지 않으면 보안 업데이트, 인증, 디지털/컴퓨터 포렌식 수사에 지장을 줄 수 있다. 로깅 시간을 UTC로 옮기면 네트워크 전체를 동기화 상태로 유지하는 데 도움이 된다.

모든 의사 결정이 그렇듯 해당 기업에 의미가 있는 것을 판단해야 한다. 작은 회사여서 관리자와 사용자 모두가 같은 시간대에 있다면 해당 시간대로 로깅하는 것이 더 적절하다. 반면 다양한 시간대의 로깅 기록을 분석하기 위해 중앙 위치 한 곳으로 모으는 경우라면, 교차 분석을 위해 UTC를 선택하는 것이 합리적이다. 로깅 및 방화벽 업체에 문의해 보는 것도 좋다.

애플리케이션에서 시간대를 선택해 주는 경우도 많다. 따라서 어떤 시간대가 선택되었는지 미리 알아둬야 한다. 예를 들어, 마이크로소프트의 웹 서버 IIS(Internet Information Services)는 다년간 UTC 시간을 기본 선택하곤 했다. KB271196에서 언급된 것처럼, IIS에서 사용하는 확장 로그 파일 형식은 필립 할람 베이커와 브라이언 벨렌도르프에 의해 W3C 워킹 드래프트 WD- logfile-960323 사양에 정의됐다. 이에 따르면 날짜와 시간 파일이 항상 그리니치 평균시(GMT)가 되도록 정의했다. GMT는 UTC와 똑같이 현재 시간을 공유한다. 현지 시간대를 원하는 경우에는 조정해야 했다.

마이크로소프트의 클라우드 플랫폼 애저의 현재 시스템 기준은 UTC이지만 언제나 그랬던 것은 아니다. 2009년에 애저의 로깅 시간을 태평양 표준시에서 UTC로 옮기기로 했다. 애저와 윈도우 디펜더 고급 위협 방지(ATP) 포털은 로깅 및 추적 정보에 UTC를 사용한다. 로컬 컴퓨터는 현지 시간대에 있지만 APT 포털의 로깅은 항상 UTC이다. 단, 메뉴의 지구 아이콘을 클릭해 컴퓨터의 현지 시간대와 UTC 간에 쉽게 전환할 수 있다.
 
윈도우 디펜더 ATP의 시간대 설정

포렌식에서는 컴퓨터가 위치한 시간대를 파악하기 위해 레지스트리를 사용하는 경우가 많다. 컴퓨터가 어떤 시간대로 설정되었는지 파악하려면 HKEY_LOCAL_MACHINE\ControlSet001\Control\TimeZoneInformation을 확인하거나 켜져 있는 컴퓨터에서 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation을 확인하면 된다. 그러면 <화면 *>처럼 컴퓨터의 시간대를 확인할 수 있다.
 
윈도우 레지스트리키에서 시간대를 확인할 수 있다.

시간과 애저, 그리고 특히 SQL을 다룰 때는 GETDATESYSDATETIME 같은 기능을 사용하는 대신 GETUTCDATESYSUTCDATETIME을 고려하는 것이 좋다. 구형 SQL 애플리케이션은 클라우드 플랫폼을 염두에 두지 않고 현지 시간을 사용해 작성된 경우가 많다. 애플리케이션을 클라우드로 옮기기 전에 UTC 시간으로 전환하는 것을 감당할 수 있는지 확인해야 한다.

마지막으로, 파워셸을 이용해 컴퓨터의 정확한 시간대를 파악할 수 있으며 일련의 원격 컴퓨터로부터 시간대를 파악할 수 있다. Get-TimeZone 명령어를 이용하면 컴퓨터의 시간대에 반응한다. 서버 목록을 붙여 여러 시스템의 시간대를 파악할 수 있다.
 
파워셸로 시간대 정의하기

정리하면, 애플리케이션, 로깅 등 시간에 민감한 모든 것을 살펴보고 UTC 시간으로 옮길 수 있는지, 아니면 현지 시간에서 UTC 시간으로 변환하기 쉬운지 판단해야 한다. 어떤 것이 기업에 더 적합하고 더 좋은 정보를 제공해 주는지도 봐야한다. 기본적으로 추가하는 클라우드 서비스가 늘어날수록, 네트워크 전체의 로깅 시간을 UTC로 옮기는 것이 이벤트 상호 연결을 위한 가장 합리적인 선택이다. ciokr@idg.co.kr


X