'DB 암호화'에 해당되는 글 3건

  1. 2013.05.03 데이터 암호화
  2. 2012.09.06 DB 암호화
  3. 2012.06.17 (2012.06.12) 개인정보 안정성 확보조치 및 위험도 분석 기준 Q&A

출처 : 네트워크 타임즈 2013.04



1. DB 암호화 프로젝트 추진 시 유의할 점

1) 키 관리

- 암호화의 기본은 키가 데이터와 같이 있으면 안 된다는 것

- 암호화 키나 인증서를 철저하게 관리한다고 하면서 HSM(Hardware Security Module)과 같은 전용

   장비가 아닌 전산실 내에 있는 서버에 보관

- 각기 다른 키가 서로 다른 관리자에 의해 관리되고 있는 상황에서는 전사적인 키관리를 통합할 필요

- 주기적인 키의 변동 등의 관리가 행해져야 한다


2) 플러그인 형태로 획일적인 암호화 방법에 의존

- 애플리케이션을 일일히 수정하자니 협업 사용자, 애플리케이션 담당자, DB 관리자 등과 협의해야

   하는 일들이 너무 많아 DB 에만 손을 대는 것

- 가장 손쉽고 현실적인 방법으로 꼽히는 플러그인 방식 DB 암호화는 당장의 규제 대응에 효과적


2. 데이터 관련 규제 대응 방법

1) 개인정보 수집 범위 선정이 우선

- 기업이 반드시 인식해야 하는 사실은, 정보를 암호화하는 것보다 개인정보 수집 범위를 어디까지

   정하고, 보관해야 하는지 기준을 세우는 것

- 업무를 하나하나 살피면서 과연 수집해온 개인정보가 꼭 필요한가 

- 어느 선까지 있어야 하는지 점검하는 것이 첫 출발점


2) 개인정보 암호화의 다양한 방식을 수용

- 개인정보 보호도 다른 분야와 마찬가지로 단일 솔루션으로 해결할 수 없다.

- 개인정보의 유형과 이 정보를 이용하고 보관하는 서비스, 애플리케이션, 기기 등을 총체적으로

   고려해 최선의 방법을 선택해야.


업무용 백 오피스 시스템에서 관리자 권한으로 다른 지점의 고객, 지점내 모든 고객의 개인정보 조회후에 엑셀로 다운로드 받는 것은 개인정보 암호화 솔루션으로는 통제할 수가 없다.

엑셀 다운로드 시점에 해당 화면, 목적, 파기예정날짜 등을 기재토록 팝업을 띄우고 해당 정보는 DB 에 보관해 컴플라이언스 팀에서 "일일 컴플 점검" 형태로 진행해야 한다.


개인정보를 암호화해도 외부에 보여질 때는 주민번호 뒷자리 등은 마스킹을 해서 보이게 한다.


개인정보 검색 솔루션을 통해서 폐기되지 않고 개인적으로 보관하고 있는 개인정보파일을 검출하고 통제해야.


DRM 등도 부가적인 솔루션이라 할 수 있고 모바일, 태블릿에도 적용 필요


3) 개발 단계부터 암호화를 반영


3. DB 암호화 고려사항


 개인정보보호법

 - 현재 발효중인 개인정보보호법의 요건에 대한 만족 여부

 - 조항의 해석과 관계없이 개인정보보호법의 사상 충족 여부

 컴플라이언스

 - PCI-DSS 등 각종 컴플라이언스 조건 만족 여부

 - 정보보호와 관련된 국내, 해외 컴플라이언스 충족 여부

 확장성

 - DB 및 시스템 환경(클라우드 등)의 변화시 확장성

 - 보호 대상의 확대 및 신규서비스 발생시 확작성

 안전성

 - 키관리에 대한 안전성

 - 발생할 수 있는 각종 해킹 등의 공격에 대한 안전성

 속도

 - 기존 업무환경의 속도와 비교

 - 향후 변경이 가능한 업무 환경의 속도와 비교


Posted by i kiss you
,

 

[출처 : 보안뉴스]

 

1. 기업의 존속과 직결되는 DB의 암호화 필요성

- 데이터 자산가치의 증가

- 내부자에 의한 정보 유출 및 보안 사고 급증

- 피해규모, 확산속도 가속 및 막대한 사회적 비용 발생

- 개인정보 유출에 대한 불안감 고조 및 신뢰성 저하

- 어플리케이션 구축 및 운영시의 보안 허점

 

2. DB 암호화의 법적 기준

 구분

소관

내용 

 정보통신망법

방통위

 시행령 제15조 (개인정보의 보호조치)

 - 주민등록번호 및 계좌번호 등 금융정보의 암호화 저장

 개인정보보호법

행안부 

 개인정보의 안정성 확보 조치 기술 고시 제7조

 - 외부망 저장시 개인정보 모두 암호화

 - 내부망 저장시 공공기관은 영향평가 결과를 통해,

   그 외 기업들은 위험도 분석 결과에 따라 시행

 

3. DB 암호화 방식과 장단점 비교

1) DB 암호화 방식

 구분

암호화 기술 

내용 

 컬럼단위  Plug - in 방식

 - 암/복호화 모듈이 DBMS 안에서 실행

 - 원래의 테이블과 동일한 이름의 뷰가 생성

 - 실제 테이블을 변경하기 위해 instead of trigger 생성

 - ORACLE, MS-SQL, DB2 사용하는 환경에 적합

 API 방식

 - 암/복호화 모듈이 어플리케이션에서 실행

 - 저장/변경 시 암호화하고, 조회 시 복호화하는 API 함수 호출

 - 뷰나 트리거 등이 생성되지 않음

 블럭단위  TDE

 - DB 커널에서 암호화된 테이블 스페이스를 생성하고,

   암호화 대상 테이블을 해당 테이블 스페이스로 이동

 - DBMS 커널에서 DB의 블록 단위로 자동으로 암/복호화 수행

 - HSM(Hard Security Machine) 어플라이언스와 연동하여 키 관리

 File 암호화

 - 암호화 파일을 사용하여 테이블 스페이스를 생성하고,

   암호화 대상 테이블을 해당 테이블 스페이스로 이동

 - OS 커널에서 DB 의 블록 단위로 자동으로 암/복호화 수행

 - HSM(Hard Security Machine) 어플라이언스와 연동하여 키 관리


2) DB 암호화 방식 장단점 비교

 암호화 기술

장점 

단점 

보안인증 

 Plug-in

 - 기존 소스 변경 최소화

 - 기존의 쿼리 변경 없음

 - 구축에 소요되는 기간 짧음

 - 최소비용

 - DBMS 서버에 부하

 - 암호화 대상 컬럼 증가시 추가 암

   호화 작업 필요

 - SQL 튜닝 필요

 - 별도 인덱스 기능 필요

 - 일부 어플리케이션 변경 필요

 국정원 인증

 (CC, 암호모듈 검증제품)

 API

 - DB 서버에 부하가 없음

 - 속도 빠름

 - 다수의 프로그램 수정

 - 장기간 소요

 - 프로그램 수정, 테스트를 위한

   비용이 크게 발생

 - 별도의 인덱스 기능 필요

 - 대량의 데이터 암/복호화 수행시

   Network Jam, 암복호화 성능 저하

 TDE

 - 어플리케이션 변경 없음

 - 성능 우수

 - 모든 데이터 타입 지원

 - DBMS 자체 인덱스 모두 사용 가능

 - DB 에 직접 접속 시, 보안성 떨어짐

 - oracle 11g 업그레이드 필요

 국정원 인증

 제품 없음

 File 암호화

 - DB 에 직접 접속 시, 보안성 떨어짐

 - 일부 OS, Volume Manager 의 경우

   지원 불가

 

4. DB 암호화 방안 선택 기준 및 보완 방안

1) DB 암호화 방안

- 금융회사 차세대 개발 계획중/개발중 -> API 방식

- 이미 구축되어 운영중인 시스템 -> Plug-In 방식

- Plug-In 방식이 불가능하다면 -> TDE, File 암호화 방식


2) DB 암호화 보완 방안

- Gateway 방식의 접근제어 솔루션 사용 시 개별 접속 컴퓨터의 IP 식별이 가능해야함

- 블럭단위 암호화 방식의 경우 암호화 컬럼을 마스킹으로 보호

 

[참고 문헌]

- 코스콤 Security Story

Posted by i kiss you
,

6월 12일 데일리 시큐 주최로 한 개인정보 위험도 분석 컨퍼런스에서 행정안전부 박사님이 말씀하신 Q&A,

그 중 몇가지 추려서 정리합니다.

 

Q 8. 서비스 제공이나 상담 등을 위해서는 회원들의 주민등록번호 앞 6자리(생년월일)를 활용할 경우가 많은데,

      주민등록번호를 모두 암호화하면 암호화/복호화에 따라 시스템에 상당한 부하가 발생한다. 별다른 방법이

      없는가?

A. 개인정보의 일부만을 암호화할 수 있다.

    생년월일 및 성별을 포함한 앞 7자리를 제외하고 뒷자리 6개 번호 이상을 암호화

주민번호가 key 로 잡혀 있다면 이럴 경우 부분 암호화 한다면 select 등에서 cost 가 높지 않을까

생각이 든다.

별도의 고객식별번호 구현이 적당해 보인다.


Q 17. 개인정보취급담당자의 정확한 기준

A, "개인정보취급자" 란 개인정보처리자의 지휘/감독을 받아 개인정보를 처리하는 임직원, 파견근로자,

    시간제근로자 등을 말한다.

 

    "개인정보처리자" 란 업무를 목적으로 개인정보파일을 운용하기 위해서 스스로 또는 다른 사람을

    통하여 개인정보를 처리하는 공공기관, 법인, 단체 및 개인을 말한다.

즉, 개인정보처리자 = 회사, 팀장, 파트장, 리터, 업무담당자, 개발자

     개인정보취급자 = 업무담당자, 개발자 등


Q 25. 임직원의 주민번호도 모두 암호화 대상입니까?

A, 임직원의 주민번호도 암호화 대상입니다.

 

Q 26. 오라클이나 MS 에서 제공하는 TDE 방식의 DB 암호화가 법적 요건을 충족할 수 있는지?

A. 일반기업의 경우 암호화 요건을 충족합니다.

    공공기관은 국정원의 인증을 받은 제품을 사용해야 한다.

금융기관은 '전자금융 감독규정'  보면 정보보호제품은 국가기관의 평가/인증을 받은 제품을 쓰라고 명시되어 있다.

금감원 트위터로 어느 정도 답은 보인다.

 

 

 

 

Q 30. DB 서버에 접속하는 단말의 경우 인터넷을 제한하는 경우 보안 패치도 업데이트 할 수 없기에 이런 경우

        는 어떻게 해야 하는지?

A. USB 통해서 한다.

 

Q 35. 위험도 분석 기준 및 해설서 기준으로 자사에서 점검하여 부서장의 결재를 득하여 보관하도록 되어

        있는데 그렇다면 제대로 분석이 되었는지에 대한 검증절차가 있어야 하는 것 아닌가요?

A. 담당자가 제대로 분석을 하면 된다.( ㅜㅜ )

 

Q 40. 위험도 분석을 어떻게 해야 하나요? 위험도 분석 전문가의 자격 기준이 있나요?

A. 별도로 없다. 내부 책임자가 한다.

 

 

 

Posted by i kiss you
,