답변:
일반적으로, 타임 스탬프는 도움말을 다양한 인증 프로토콜에 방지 사용되는 재생 공격 (네트워크 스니핑하여 예) 그는 훔칠 수 있었다 토큰 공격자가 인증을 다시 사용할 수 있습니다.
예를 들어 Kerberos 인증은이를 정확하게 수행합니다. Windows에서 사용되는 Kerberos 버전에서 기본 허용 오차는 5 분입니다.
이는 또한 Google OTP, RSA SecurID 등과 같은 2 단계 인증에 사용되는 다양한 일회성 비밀번호 프로토콜에서도 사용됩니다. 이러한 경우 허용 오차는 보통 약 30-60 초입니다.
클라이언트와 서버간에 시간이 동기화되지 않으면 인증을 완료 할 수 없습니다. (이 제한은 요청자와 KDC가 인증하는 동안 시계 사이의 오프셋을 결정하도록함으로써 최신 버전의 MIT Kerberos에서 제거되었지만 이러한 변경은 Windows Server 2012 R2 이후에 발생했으며 Windows에서 볼 때까지는 시간이 걸립니다. 그러나 2FA의 일부 구현에는 항상 동기화 된 시계가 필요할 수 있습니다.)
시계를 동기화하면 이기종 시스템에서 더 쉽게 작업 할 수 있습니다. 예를 들어, 모든 시스템의 시간이 같은 경우 여러 서버의 로그 항목을 상관시키는 것이 훨씬 쉽습니다. 이 경우 일반적으로 1 초의 허용 오차 (NTP에서 제공)를 사용하여 작업 할 수 있지만 시간을 최대한 여유있게 동기화하려는 것이 이상적입니다. 더 엄격한 공차를 제공하는 PTP는 구현하는 데 훨씬 더 비쌀 수 있습니다.
make또한 클라이언트 / 서버 NFS 사이의 클럭 차이로 인해 혼동됩니다.
주로 여러 장치의 로그에서 발생한 사건을 상호 연관시킬 수 있습니다. 누군가가 웹 서버를 통해 데이터베이스에 액세스하는 보안 사고가 있다고 가정합니다. 방화벽,로드 밸런서, 웹 서버 및 데이터베이스 서버의 타임 스탬프를 모두 일치시켜 각 장치에서 로그를 찾을 수 있습니다. 사건과 관련이 있습니다. 이상적으로는 모든 것이 몇 밀리 초 안에 들어가기를 원합니다. 또한 실제 외부 시간과 동기화되어야하므로 필요할 경우 타사 로그와 로그를 상호 연관시킬 수도 있습니다.
관리 관점에서 중요 할뿐만 아니라 클럭을 동기화하는 것이 응용 프로그램 수준 상관 관계에서도 중요합니다. 이는 솔루션 설계 방식, 실행중인 애플리케이션이 작업 할 수있는 트랜잭션에 대한 타임 스탬프를 얻는 방법에 따라 다릅니다. 상호 작용하는 다른 시스템에 비해 너무 많은 오프셋 (약 20 초 정도)으로 서버에서 실행되는 응용 프로그램으로 인해 트랜잭션 유효성 검사가 실패하는 것을 보았습니다.
또한 예를 들어 VMWare ESXi 서버에서 가상화하고 VM의 시간이 하이퍼 바이저의 시간과 동기화되지 않으면 vmotion과 같은 조치로 VM 시계가 하이퍼 바이저와 다시 동기화 될 수 있으며 이로 인해 예기치 않은 결과가 발생할 수 있습니다. 시차가 충분히 큰 경우.
실제 공차가 무엇인지는 알지 못합니다. 왜냐하면 그것이 어떤 유형의 시스템에 달려 있는지 생각하기 때문에 일반적으로 말하면 데이터 센터의 서버를 서로 1 초 미만의 간격으로 유지하는 것이 가능하다고 생각합니다.
윤초를 언급 했으므로 특히 어려운 처리가 필요합니다.
일반적으로 초를 23:59:60으로 삽입하여 추가됩니다. 분 및 초 필드에서 타임 스탬프를 0-59로 유효성 검사하는 경우 문제가됩니다. 2 초 길이로 23:59:59를 반복하는 방법은 초당 수준까지 민감한 타이밍을 망칠 수 있기 때문에 그리 나쁘지 않습니다.
구글은 실제로 아직 널리 채택되지 않은 것 같은 좋은 솔루션을 생각해 냈습니다. 그들의 해결책은 도약 "번짐"을 적용하고 전체 프로세스를 NTP 서버가 관리하는 일정 기간에 걸쳐 변경 사항을 분할하는 것입니다. 그들은 2011 년에 그것에 관한 블로그 를 출판했고 , 흥미로운 독서를하고이 질문과 관련이있는 것 같습니다.
위의 모든 사항에 동의합니다. 나는 더 많은 생각을 던져하려는
등 일부 데이터베이스 Cassendra는 타임 스탬프에 의존을 . 이것이 동시성을 다루는 방식입니다.
다른 타임 스탬프는 데이터베이스를 완전히 엉망으로 만듭니다.