개인정보 분리 보관 편집하기

IT위키

경고: 로그인하지 않았습니다. 편집을 하면 IP 주소가 공개되게 됩니다. 로그인하거나 계정을 생성하면 편집자가 사용자 이름으로 기록되고, 다른 장점도 있습니다.

편집을 취소할 수 있습니다. 이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 게시해주세요.

최신판 당신의 편집
1번째 줄: 1번째 줄:


개인정보 보호법제상 개인정보 분리 보관이란 개인정보 보호법상 원칙적으로 삭제를 해야 하나 다른 법률상의 규정에 따라 불가피하게 보관을 해야 하는 경우를 말한다. 주로 접근 통제, 권한 구분을 목적으로 한 분리 보관을 의미한다.  
개인정보 보호법제상 개인정보 분리 보관이란 개인정보 보호법상 원칙적으로 삭제를 해야 하나 다른 법률상의 규정에 따라 불가피하게 보관을 해야 하는 경우를 말한다. 주로 활용과 접근 권한 분리를 목적으로 한 분리 보관을 의미한다.  


==근거 법령==
==근거 법령==
12번째 줄: 12번째 줄:
|}
|}


*그 외 전자상거래법, 근로기준법 등 보관 의무를 명시한 별도 법률 조문들
* 그 외 전자상거래법, 근로기준법 등 보관 의무를 명시한 별도 법률 조문들
 
==분리 보관의 의의==
개인정보 보호법제상 분리 보관이란 활용과 접근 권한 분리를 목적으로 한 분리 보관을 의미한다. 주로 개인정보 보호법상 원칙적으로 삭제를 해야 하나 다른 법률상의 규정에 따라 불가피하게 보관을 해야 하는 경우를 말한다.
 
*유사시에 데이터 소실을 방지하거나 [[사이버 복원력]]을 위한 분리 보관, 무결성 유지를 위한 분리 보관도 있으나 이는 [[백업]]이나 [[소산]]과 같은 별도 기준이 적용되는 경우<ref>개인정보처리시스템의 개인정보처리자 접근기록 보관 등의 경우가 이에 해당하는데, 이런 경우는 "위·변조 및 도난, 분실되지 않도록 안전하게 보관"하라고 적혀있어 조문상 목적에 대한 구분이 가능하다.</ref>로, 일반적인 분리 보관은 정보의 오남용 방지 및 보호에 관점을 두어야 한다.


==분리 보관 방법==
==분리 보관 방법==
22번째 줄: 27번째 줄:


*동일한 데이터베이스, 동일한 스키마에서 테이블만 구분한다.
*동일한 데이터베이스, 동일한 스키마에서 테이블만 구분한다.
**예) 기존 회원 테이블을 tb_user로, 분리보관된 회원 테이블을 tb_user_archive로 구분하여 운용
**예) 기존 회원 테이블을 tb_user로, 분리보관된 회원 테이블을 tb_user_archive 로 구분하여 운용
*접근 권한 분리가 어렵다.
*접근 권한 분리가 어렵다.
*데이터베이스에 대한 침해가 발생한 경우 다른 테이블과 같이 피해를 볼 확률이 높다.
*데이터베이스에 대한 침해가 발생한 경우 다른 테이블과 같이 피해를 볼 확률이 높다.
42번째 줄: 47번째 줄:
'''컨테이너 분리'''
'''컨테이너 분리'''


*[[서버 가상화|가상화 서버]]를 사용하는 경우, 동일한 물리적 서버에서 [[하이퍼바이저]]나 [[컨테이너 가상화|컨테이너]] 수준으로 저장소를 구분하여 운용한다.
*가상화 서버를 사용하는 경우, 동일한 물리적 서버에서 컨테이너 수준으로 구분하여 운용한다.
*서버 수준의 침해에서도 다른 가상화 서버에 대한 침해에는 영향을 받지 않는다.
*서버 수준의 침해에서도 다른 컨테이너에 대한 침해에는 영향을 받지 않는다.
**[[스펙터]]나 [[하트블리드]] 같은 심각한 침해에선 다른 컨테이너를 통한 침해도 가능하지만 확률이 매우 낮다.
**[[스펙터]]나 [[하트블리드]] 같은 심각한 침해에선 다른 컨테이너를 통한 침해도 가능하지만 확률이 매우 낮다.
*별도의 서버를 운용하는 것과 같이 권한 분리 및 접근 통제가 가능하다.
*별도의 서버를 운용하는 것과 같이 권한 분리 및 접근 통제가 가능하다.
63번째 줄: 68번째 줄:
예를 들어 테이블 분리는 상대적으로 간편하지만 분리의 수준이 낮은 다소 위험한 방법으로 알려져 있으며 감사 시에도 지적을 받을 수 있으나, DBMS 보안 솔루션 등을 통해 해당 테이블에 대한 접근 권한을 완전히 구분하고 암호키 또한 별도로 사용하고 있다면 적절한 분리 보관으로 인정될 수도 있다.<ref>물론 이는 점검 기준에 따라 달라질 수 있다. 원칙적으로 인정되지 않는 경우도 많다.</ref>
예를 들어 테이블 분리는 상대적으로 간편하지만 분리의 수준이 낮은 다소 위험한 방법으로 알려져 있으며 감사 시에도 지적을 받을 수 있으나, DBMS 보안 솔루션 등을 통해 해당 테이블에 대한 접근 권한을 완전히 구분하고 암호키 또한 별도로 사용하고 있다면 적절한 분리 보관으로 인정될 수도 있다.<ref>물론 이는 점검 기준에 따라 달라질 수 있다. 원칙적으로 인정되지 않는 경우도 많다.</ref>


단순히 분리의 수준만 높이는 것보다 해당 분리 수준에서 적용할 수 있는 보안 대책을 잘 설정하는 것이 더 중요하다. 분리 보관된 데이터에 대해 암호화 항목을 늘리고 암호화 키를 별도로 사용할 수도 있고 접근할 일이 아예 없거나 많지 않은 데이터의 경우엔 아예 접근 경로를 막아 놓는 방법 또한 강구할 수 있다.
단순히 분리의 수준만 높이는 것 보다 해당 분리 수준에서 적용할 수 있는 보안 대책을 잘 설정하는 것이 더 중요하다. 분리보관된 데이터에 대해 암호화 항목을 늘리고 암호화 키를 별도로 사용할 수도 있고 접근할 일이 아예 없거나 많지 않은 데이터의 경우엔 아예 접근 경로를 막아 놓는 방법 또한 강구할 수 있다.


==분리 보관이 필요한 규정==
==분리 보관이 필요한 규정==
IT위키에서의 모든 기여는 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 라이선스로 배포된다는 점을 유의해 주세요(자세한 내용에 대해서는 IT위키:저작권 문서를 읽어주세요). 만약 여기에 동의하지 않는다면 문서를 저장하지 말아 주세요.
또한, 직접 작성했거나 퍼블릭 도메인과 같은 자유 문서에서 가져왔다는 것을 보증해야 합니다. 저작권이 있는 내용을 허가 없이 저장하지 마세요!
취소 편집 도움말 (새 창에서 열림)