it-swarm-korea.com

웹 애플리케이션 용 PCI에 대한 로깅 요구 사항

PCI는 애플리케이션 수준에서 얼마나 많이 기록해야하나요? 아니면 단순히 기록하면 안되는 항목을 지정하나요?

나는 지금 너무 많은 벌목으로 어려움을 겪고 있으며 우리가 그것을 가져야한다고 생각하는 사람들도 있습니다. 디버깅 관점에서 나는 과거에 과도한 로깅이 거의 쓸모 없다는 것을 발견했으며 Jeff Atwood on exception only logging 에 동의합니다.

나는 현재 내가 지원하는 애플리케이션의 로깅의 약 99 %에 AspectJ를 사용하고 있으므로 이러한 예외에 대한 로그를 검토 할 때와 상당한 공간을 차지하기 시작하는 경우를 제외하고는 큰 문제가 아닙니다. .

12
Casey

다음을 기록해야합니다.

  • 카드 소지자 데이터에 대한 모든 개별 액세스
  • 루트 또는 관리 권한을 가진 개인이 수행 한 모든 작업
  • 모든 감사 추적에 대한 액세스
  • 잘못된 논리적 액세스 시도
  • 식별 및 인증 메커니즘 사용
  • 감사 로그 초기화
  • 시스템 수준 개체의 생성 및 삭제

변경 불가능한 방식으로 확인 가능한 날짜 및 시간 (적절한 시간 동기화 사용)으로 기록되어야합니다. "최소한 1 년 동안 감사 추적 기록을 보관하고 최소 3 개월 동안 즉시 분석에 사용할 수 있습니다 (예 : 온라인, 아카이브 또는 백업에서 복원 가능)."

전체 문서를보고 큰 12 개를 구성하는 모든 하위 요구 사항을 이해하고 싶을 것입니다. https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

하지만 Jeff Atwood 이론에 답하고 자신의 온전함을 유지하려면 PCI DSS 관련 로그를 애플리케이션 활동 로그와 별도로 보관해야합니다. 예외는 별도의 로그 기능에 복사 할 것을 제안합니다. 개발자의 관점에서 보면 로그는 읽기 쉽고 희소합니다. 감사 자의 관점에서 보면 포괄적 인 로그는 활동을 재구성하는 데 사용할 수 있습니다.

11
Jeff Ferland

레벨 1 규정 ​​준수로 태그 된 여러 비즈니스가 기본적으로 제공되는 것 이상으로 애플리케이션 로깅을 수정하려는 노력이 거의 또는 전혀없이 규정 준수를 달성하는 것을 보았습니다. 준수 확인 표시를 얻으려면 거의 표시하지 않고 수행 할 수 있습니다 (감사 자 불일치는 여전히 와일드 카드입니다).

즉, 다음은 결제 애플리케이션과 관련하여 결제 애플리케이션 데이터 보안 표준 (v. 2.0/2010 년 10 월)의 관련 로깅 스 니펫입니다. 활동 :

alt textalt text

5
Tate Hansen