Privacy Violation: Unobfuscated Logging

고객 암호 또는 주민 등록 번호 등의 개인 정보 취급 부주의는 사용자 개인 정보를 침해할 수 있고 불법인 경우가 있습니다.

Privacy Violation은 다음 경우에 발생합니다.

1. 사용자 개인 정보가 프로그램에 입력됩니다.
2. 데이터는 콘솔, 파일 시스템 또는 네트워크와 같은 외부 위치에 작성됩니다.

예제 1: 다음 취약한 코드에는 기밀 "admin_password"가 난독 처리되지 않은 상태로 로깅되도록 허용하는 구성 문이 포함되어 있습니다.

from oslo_config import cfg
 ...
opts = [
  cfg.StrOpt('admin_password',secret=False,
               help="User's password")]
 ...              
grp = cfg.OptGroup('mygroup')
cfg.CONF.register_opts(opts, group=grp)
 ...
logger.warning("Adding %s" % cfg.CONF.mygroup.admin_password)

Example 1의 코드는 secret 값이 False로 설정된 상태로 admin_password를 일반 텍스트(난독 처리되지 않음)로 로그 출력에 씁니다. 많은 개발자가 이벤트 로그를 안전한 데이터 저장소로 신뢰하지만 무조건 신뢰해서는 안 됩니다. 특히 개인 정보가 관련된 경우가 대표적입니다.

개인 정보는 다음과 같은 다양한 방식으로 프로그램에 입력됩니다.

- 암호 또는 개인 정보의 형태로 사용자가 직접 입력

- 응용 프로그램이 데이터베이스 또는 기타 데이터 저장소에서 접근

- 협력업체 또는 타사를 통해 간접적으로

개인 정보로 명명되지 않은 데이터도 상황에 따라 개인 정보로 해석될 수 있습니다. 예를 들어, 학생 ID 번호는 명시적이고 공개적으로 각 학생의 개인 정보에 매핑되지 않기 때문에 보통 개인 정보로 간주하지 않습니다. 하지만 학교에서 학생의 주민 등록 번호를 기반으로 ID 번호를 생성하는 경우 ID 번호는 개인 정보로 간주해야 합니다.

보안 및 개인 정보 문제는 서로 상충하는 것처럼 보일 때가 있습니다. 보안 관점에서 보면 이후에 비정상적인 활동을 식별할 수 있도록 모든 중요한 작업을 기록해야 합니다. 하지만 개인 정보가 관련된 경우 이 방법은 위험이 따릅니다.

개인 정보를 위험하게 처리하는 방법은 여러 가지가 있겠지만 공통적인 위험은 잘못된 신뢰에서 비롯됩니다. 프로그래머는 프로그램이 실행되는 운영 환경을 신뢰하기 때문에 개인 정보를 파일 시스템, 레지스트리 또는 기타 로컬로 제어되는 리소스에 저장해도 무방하다고 생각합니다. 하지만 특정 리소스에 대한 접근이 제한되어 있는 경우에도 접근 권한을 가진 개인을 신뢰할 수 있다고 보장할 수 없습니다. 일례로, 2004년, AOL의 한 비양심적인 직원이 해외 도박 웹 사이트를 대상으로 영업하는 스패머에게 약 9천 2백만 개의 고객 전자 메일 주소를 팔았습니다[1].

이런 대형 익스플로이트 사건에 대응하여 개인 정보 수집 및 관리에 대한 규제가 점점 엄격해지고 있습니다. 조직의 위치, 업종 및 취급하는 개인 정보의 속성에 따라 조직은 다음의 연방 정부 및 주 정부의 규제를 하나 이상 준수할 의무가 있습니다.

- 세이프 하버 협정(Safe Harbor Privacy Framework)[3]

- GLBA(Gramm-Leach Bliley Act)[4]

- HIPAA(Health Insurance Portability and Accountability Act)[5]

- California SB-1386 [6]

이런 규제에도 불구하고 Privacy violation은 우려할 만한 빈도로 계속 발생하고 있습니다.