하트블리드(Heartbleed) 취약 방지 솔루션 Thales-HSM

작성자 : 아이마켓코리아 아이마켓코리아 / 날짜 : 2014.05.28 11:28 / 카테고리 : nCipher HSM (Thales-HSM )




[하트블리드 - Heart Bleed]

하트블리드는 우리가 계속 당면하고 있는 보안을 위협하는 또 하나의 버그입니다. 하트블리드 버그는 인터넷을 통해 오픈SSL 소프트웨어의 취약한 버전으로 보호하는 시스템의 메모리를 읽을 수 있게 합니다. 이는 서비스 제공자를 확인하는데 사용하는 보안키를 위태롭게 하고 사용자의 교신 내용, 이름, 비밀번호와 실제 콘텐츠를 암호화 합니다.


이 버그는 공격자가 다른 사람의 통신 내용을 도청하고 서비스와 사용자들의 데이터를 직접 훔치며 당사자로 가장할 수 있게 합니다. 또한 이 버그는 생산 소프트웨어 속에 2년 이상 잠복해 왔으며 유수 보안 전문가들이 ‘대참사’를 유발할 만한 것으로 지목하고 있습니다.



이를 즉각 해결하려면 감염된 시스템을 확인해서 이를 교정하고 SSL 인증을 업데이트해야 합니다. 사용자들에게는 또 비밀번호를 바꿀 것과 노출된 정보의 추적 오용 위험성을 통보할 필요가 있습니다.


비록 버그를 오늘 교정했다 하더라도 유사한 버그가 다시 표면으로 나타나던가 소프트웨어 속에 숨어 있지 않는다고 보장할 수 없습니다. 이와 유사한 영향력을 가진 취약성은 향후 다른 SSL라이브러리나 애플리케이션에서 일어날 수도 있습니다.



비록 SSL 암호가 뚫린다 해도 민감한 데이터의 노출을 방지하려면 기업체들은 비밀번호와 민감한 데이터의 거래를 보호하기 위해 ‘단 대 단 암호’(End-to-End Encryption (E2EE)와 같은 강력한 데이터 보호 솔루션이 필요합니다.


E2EE는 민감한 데이터가 취약한 웹의 메모리나 애플리케이션 서버 안에 있다 하더라도 암호화 상태를 그대로 유지하게 합니다. 이는 하트블리드 형태의 버그로부터 데이터를 보호할 뿐 아니라 소프트웨어 개발자나 데이터베이스 관리자(DBA)와 같은 내부자가 실수로 또는 고의로 민감한 데이터를 누출하는 것을 방지합니다.


실제로 싱가포르통화청(MAS)과 홍콩통화청(HKMA)은 금융기관들이 전자금융 사이트의 비밀번호와 중요한 거래 데이터를 보호하기 위해 E2EE를 채택할 것을 의무화하고 있는 추세입니다.


많은 금융기관들과 마찬가지로 다른 기관들도 통신채널을 통해 암호화된 비밀번호와 민감한 데이터를 전송하기 위해서는 SSL 소프트웨어 외에 이 같은 최상의 암호화 솔루션을 채용해야 합니다. 이는 데이터를 서버로 보내기 전에 진입점(사용자 데스크톱PC/스마트폰)에서 암호화 라이브러리와 데이터 암호화를 위한 핵심 데이터를 사용해 성취할 수 있습니다.



이렇게 하면 데이터가 웹 서버와 애플리케이션 서버에 이를 때까지 암호화된 상태를 유지할 수 있습니다. 데이터가 애플리케이션 서버에서 해독될 가능성이 있으나 비밀번호의 경우는 하드웨어 보안 모듈(Hardware Security Module, HSM) 안에서 암호화되고 입증된 상태를 유지합니다.



HSM은 미국 연방정보처리표준(FIPS)을 충족시킬 수 있는 변형 억제 하드웨어를 사용한 암호화 디바이스입니다. 이처럼 비밀번호는 진입점에서부터 비교점까지 암호화되며, 이 방식은 하트블리드 형태의 취약성을 완화시키는 것 외에 인트라넷에 있는 사람이 전송 및 저장 과정에서 아무도 비밀번호에 접근하지 못하게 할 뿐 아니라 내부 사기로부터 보호할 수 있게 합니다.


요약하면 데이터를 효과적으로 보호하려면 여러 계층으로 된 보안 솔루션과 올바른 처리 절차를 결합해야 합니다. 기관(기업)들은 새로운 웹 서버 취약성으로부터 비밀 정보를 보호하기 위해 SSL 보안 소프트웨어에만 의존할 것이 아니라 애플리케이션 계층에서 E2EE솔루션을 사용해야 합니다.

※ 출처 :  http://www.cctvnews.co.kr/atl/view.asp?a_id=9836 (CCTV NEWS 이광재 기자)




요번 SSL 취약성은 정말 심각한 것으로써, 여러분들이 사용하시는 웹서버 서비스 상(인터넷뱅킹, 카드사 홈페이지, 보험사 등등) 의 모든 패스워드 를 바꾸라고 합니다.  



우리나라도 open SSL 을 사용하는 비율이 약 70% 에 달하는 것으로 알고 있습니다. 본 보안 취약성은 google 등에 의해 발표되었지만 이미 해커들에 의한 공격이 있었으면 모든 https 상의 정보는 해커에게 넘어갔다고 볼 수 도 있을 것입니다. 저희 HSM 을 openSSL 에 연동하는 방법은 간단합니다. 


HSM 을 구매하시고 웹로직, APACHE, 톰캣 등의 웹서버는 이미 Thlaes HSM 과 연동이 되어 있습니다. 혹은 vendor define 된 SSL 을 사용중이신 경우에는 PKCS#11 을 통한 연동작업이 필요하나, Softforum 과 Initech 의 경우에는 이미 연동이 되어 있습니다.

아래는 기사에 발표된 openSSL 보안 취약점인 heartbleed 에 대한 간단한 내역입니다.


 


[하트블리드 취약점이란?]

하트블리드는 인터넷의 핵심 암호화 기술로 활용되고 있는 오픈SSL의 심각한 취약점입니다. 오픈SSL은 많은 웹사이트를 비롯해 전자메일, 인스턴트 메시징 및 VPN과 같은 애플리케이션에서 사용되고 있습니다.


이 취약점이 악용되면 사용자의 개인정보, 비밀번호뿐만 아니라 웹서버의 암호키도 탈취될 수 있습니다. 이 취약점을 이용해 정보유출이나 해킹을 시도해도 흔적이 남지 않기 때문에 피해 여부를 알 수 없는 것도 문제입니다.


취약점이 발견된 오픈SSL 버전은 오픈SSL 1.0.1~1.0.1f, 오픈SSL 1.0.2-beta, 오픈SSL 1.0.2-beta1 입니다. 이 취약점을 해결하려면 오픈SSL 공식 홈페이지에서 배포된 오픈SSL 1.0.1g 버전으로 업데이트해야 합니다.

※ 출처 :  http://outofcontrol.co.kr/?p=985&fb_action_ids=244213472433205&fb_action_types=news.publishes&fb_ref=pub-standard


 

Thales의 nShield HSM for Web Service를 통해 하트블리드(Heart Bleed) 취약점 문제를 미연에 방지할 수 있는 솔루션을 구축해 보시기 바랍니다.


[Thales HSM 사용시 장점]

■ 성 능

   - 암호화 세션 연결 시 HSM의 SSL 가속 기능을 사용하여, 암호화 세션 연결성능이 향상됩니다.


■ 가용성

   - 암호화 세션 연결시 HSM의 SSL 가속 기능을 사용하여, 업무서버에 암호화세션 연결 부하를 주지 않기 때문에, 업무 서버의 시스템 

     가용성이 향상됩니다.


■ 보 안

   - 서버의 개인키가 HSM으로 관리 되기 때문에, 키 보호 측면에서 보안성이 향상됩니다.



[SSL이 적용된 일반적인 웹서비스 구성]


[HSM을 이용한 SSL 웹서비스 시스템 구성]


[HSM과 SSL 가속기를 이용한 SSL웹서비스 시스템 구성]





Trackbacks 0 / Comments 0

DB암호화 - 설계

작성자 : 아이마켓코리아 아이마켓코리아 / 날짜 : 2014.05.12 18:24 / 카테고리 : nCipher HSM (Thales-HSM )

DB암호화 - 설계


DB 암호화를 구축하기 위해서는 복호화 권한통제, 암호 키 정의, 그리고 암호화 키 사용 로깅 등 많은 사항을 고려하여야 한다. 

암호화 규칙은 DB를 암호화하기 위한 기본적인 전 제 조건과 고려사항을 언급한 것이며, 암호화를 규칙대로 적용하고 암호화 후 정상적인 DB 서비스를 지속시키기 위한 몇 가지 지표를 다음과 같이 정리할 수 있다.

1. DB에 접속할 수 있는 사용자에 대한 정의가 되어 있는가?

2. DB에 접속하는 사용자 식별에 대한 방법이 정의 되었는가?

3. 암호화 대상 컬럼의 범위는 정의하였는가?

4. 암호화 컬럼에 대한 복호화 권한 통제를 수행 하는가?

5. 암호화 키를 위한 알고리즘과 대상을 정의하였는가?

6. 암호화 키 사용에 대한 로깅을 수행하는가?


가. 복호화 권한 통제

DB 컬럼(Column) 암호화가 수행되면 데이터 보호를 위해 인가된 사용자에게 복호화 된 평문 데이터(Plain Data)를 전송한다. 

하지만 비인가 사용자에게는 암호화된 데이터나 일 부 암호화(마스킹-Masking)된 데이터를 전송하게 된다.

1) 사용자 식별

DB에 접근하는 경우는 다음과 같이 정의할 수 있다.

1. 웹(Web)이나 애플리케이션 서버(Application Server)의 정형적인 접근

2. DB 관리자에 의한 비정형 접근

3. 프로그램 개발자나 유지보수 지원 엔지니어에 의한 비정형 접근


정형적인 접근(Bulletin Job)이란 기업내의 특정 업무 수행을 위해 정기적으로 DB에 접 속하여 반복적인 SQL 작업을 수행하는 것을 의미하며, 변하지 않는 정해진 SQL을 DB에 요청하는 경우를 의미한다. 대체로, 웹 서버나 애플리케이션 서버가 이러한 경우에 해당 하며 때로는 성능관리나 장애관리용 모니터링(Monitoring) 솔루션도 이에 해당한다. 물 론, 웹 서버나 애플리케이션 서버내의 DB 접속 도구(DB Tool - 예를 들어, Oracle의 SQLPLUS)에 의한 DB 접속은 정형적인 접근이라 할 수 없으며 비정형 접근(Non- Bulletin Job)에 해당한다.

비정형 접근(Non-Bulletin Job)이란 시스템 유지보수나 애플리케이션의 개발을 위해 DB에 접속하여 데이터를 변경, 삭제 및 조회하는 작업을 의미한다. DB 관리자(DBA)라 하더라도 DB 내의 데이터를 조작할 권한은 없기 때문에 DB 관리자에 의한 DB 접속도 비 정형 작업에 해당하므로, 정확한 권한 분리(Separation of Duty)를 진행하여야 한다.



암호화된 DB 측면에서 볼 때, 민감한 데이터 보호를 위해 복호화 된 평문 데이터를 전송할 대상을 식별(사용자 식별)하기 위하여 상기의 DB 접속 정보를 구분할 수 있는 경우는 다음 과 같다.

1. DB 접속 날짜 및 시간

2. IP Address 및 호스트 네임(Host Name)

3. DB 계정 (DB User)

4. 애플리케이션 이름 (Application Name)


플러그인(Plug-In) 방식의 컬럼 암호화(Column Level Encryption)의 경우, DB에 접속 하는 DB 클라이언트(Client)의 위와 같은 접속 정보 조합을 통해서 복호화의 대상을 식별 할 수 있다. 반면 API 방식 컬럼 암호화의 경우 데이터의 암복호화 작업이 애플리케이션 서버 상에서 수행되기 때문에 상기의 DB 접속정보를 통한 사용자 식별은 해당되지 않는 다. 즉, API방식 컬럼 암호화는 애플리케이션 서버에 접속하는 애플리케이션 서비스 접속 자의 식별만 가능하므로 DB 서버에 직접 접속하는 DB 사용자의 식별은 불가능하다. 따라 서, API방식의 경우 DB 관리자에 의한 암호화된 데이터 변경 및 관리에 어려움이 따른다.


2) 암호화 대상 컬럼

DB 컬럼 암호화의 주요 목적은 개인정보나 민감한 정보가 담겨 있는 테이블의 컬럼 정보 를 비인가자로부터 보호하는 것이다. 암호화 대상의 컬럼의 경우 DBMS에서 지원하는 다 양한 종류의 데이터 타입을 가지게 되는데, 일반적으로 개인정보의 이름, 주소, 생년월일, 카드번호, Email 주소 등 스트링(String) 타입이 컬럼 암호화 대상이 되는 경우가 많고, 도면이나 음성, 이미지, 바이오 정보 등의 바이너리(Binary) 타입의 경우와 그 외 숫자 타 입을 가지는 경우도 있다.

DB 컬럼의 경우 성능향상을 위해 인덱스(Index)를 자주 사용하게 되는데, 암호화 컬럼의 데이터 타입에 따라서 인덱스에 컬럼 값이 그대로 노출되는 경우가 있기 때문에 컬럼을 암 호화 할 경우 관련 인덱스도 암호화의 대상이 되어야 한다. 즉, 인가된 사용에게 복호화 권 한을 통제하기 위해서는 컬럼뿐만 아니라 인덱스도 복호화 권한 관리 대상에 포함되어야 한다.


3) 암호화 컬럼에 대한 복호화 권한통제

암호화의 대상은 다수의 테이블에 존재하는 다수의 컬럼이다. 하나의 테이블에 존재하는 서로 다른 컬럼이라 하더라도 사용자를 식별하여 복호화를 할 필요가 있다. 대체로, 테이블과 컬럼은 하나의 DB 계정(DB User)에 의해 소유되지만, DB 계정은 여러 사용자에 의해 공유될 수 있고, 이에 따라 테이블에 각기 다른 정보를 담고 있는 컬럼들의 경우 복호화의 권한 제한을 설정할 필요가 있다.


4) 비인가 사용자에 대한 통제

암호화된 데이터는 인가된 사용자나 시스템에게는 정상적인 복호화 데이터를 전송하지만, 비인가 사용자에게는 암호화된 데이터나 일부 암호화(사용자 입장에서는 Masking으로 보일 수 있음) 데이터를 전송하게 된다. 다음은 이러한 비인가 사용자에게 적용할 수 있는 보안의 적용 사례를 살펴보고자 한다.




■ Encrypt Null

“Yes”을선택하면, NULL 값도 암호화하며,“ No”을 선택하면 암호화 후에도 NULL로 값이 유지 된다.


■ If access denied

암호화된 컬럼에 접근사용 권한이 없는 경우

?Return Null : 비인가 사용자에게 암호화된 컬럼 값으로“NULL”을 반환

?Return user value : 비인가 사용자에게 사용자 정의된 값을 반환. 만일 “NULL” 스트링을 입력하면 실제 NULL값을 반환하고, BLOB 타입은 지원하지 않음

?Character 타입column 경우→임의의Character를사용“( ”제외)

Number 타입 column 경우 → 숫자대신“.”혹은 다른 (숫)문자 사용

Date 타입 column 경우 → TO_TIMESTAMP 함수로 변환 예

?Return mask : 비인가 사용자에게 마스킹(* 혹은 다른 글자) 된 스트링 값을 반환.

설정 값에 따라 앞의 몇 글자 혹은 뒤의 몇 글자가 마스킹. 이 옵션은 Character 타 입의 컬럼만 지원

?Return encrypted : 비인가 사용자에게 암호화된 스트링을 그대로 반환하며,

Character 타입의 컬럼일 경우만 지원. BLOB이상의 큰 사이즈는 지원하지 않음


나. 암호화 키 및 알고리즘 정의

암호화 키는 암호화 알고리즘(Encryption Algorithm)과 파라미터 키(Parameter Key) 의 조합이라 할 수 있다. 암호화 방식은 대칭형(Symmetric)과 비대칭형(Asymmetric) 방식으로 나뉘는데, 대칭형은 암호화 키와 복호화 키가 동일하고, 비대칭형은 암호화 키 와 복호화 키가 상이하다.



대표적인 암호화 알고리즘으로 대칭형 알고리즘은 DES, 3-DES, AES, SEED, ARIA, MASK가 있고, 비대칭형 알고리즘은 RSA, DSA가 있다.



암호화 키는 컬럼 별로 독립적으로 적용될 수 있다. 즉, 하나의 테이블 내에 존재하는 컬럼 일지라도 컬럼 별로 암호화 키를 독립적으로 정의할 수 있다. 암호화 키에 사용되는 암호 화 알고리즘의 특성에 따라 성능과 보안성의 차이가 존재하므로 암호화 대상 DB의 성격과 주위 연계 시스템과의 관계를 고려하여 적용한다.


1) 대칭형 알고리즘

대칭형 암호에는 크게 두가지 유형이 있는데 블록 암호(Block Chiper)방식과 스트림 암호 (Stream Chiper)방식이 있다. 스트림 암호 방식은 블록 암호방식보다 2배 정도 빠르지만 고유키(Unique Key)를 사용해야 한다. 블록 암호 방식은 키의 재사용(Reuse)이 가능하 고 DB 암호화의 대부분은 블록암호 방식을 사용하는 경향이 있다. 대칭형 암호 방식의 경우 키길이를 최소 128bit로 할 것을 권장하는데, 키 길이는 암호화 된 데이터에 대한 공격(주로 2가지 방법이 이용됨)으로 부터 보호하기 위한 매우 중요한 요소로 자리잡고 있다.

첫번째 공격방법은 추측과 확인(Guess and Check)형태의 공격으로서 알고리즘이 잘못 구현되었거나 잘못된 랜덤(Random) 변수에 의해 적용되었을 경우, 해커들은 임의의 키 를 적용하고 데이터를 확인하는 작업을 반복함으로써 암호화된 데이터를 복호화한다. 두번째 방법은 브루포싱(Brute Forcing) 기법을 통해 무작위로 키를 대입하여 확인하는 작업이다. 예를 들면, DES 알고리즘의 짧은 56bit 키길이의 경우 24시간내에 해독이 가 능하다. 따라서 대칭키 암호방식을 택한 경우 최소 128bit의 키 길이를 권장한다. DB 암호화를 위하여 자주 사용되는 대칭키 암호 방식에는 AES, DES, 3DES, RC5 등 블록 암호방식이 있다. RC4 알고리즘의 경우 스트림 암호방식도 사용 가능하나 매번 암호 화할 때마다 고유키가 필요하므로 매우 복잡해진다. 블록암호방식의 가장 큰 장점 중의 하 나는 기존키의 재사용이 가능하고 작은 크기의 데이터 암호화 수행이 매우 뛰어나다는 것 이다. DES, 3DES, AES의 알고리즘이 대칭형 방식에서 가장 널리 사용된다.


2) 비대칭형 알고리즘

비대칭형 알고리즘의 경우 한쌍의 키조합이 필요한데, 암호화에 사용된 키와 복호화에 사 용된는 키가 다름에도 수학적 원리에 의해 해독이 가능하도록 한 방식이다. 이 알고리즘은 공개키로 매우 유명하며, PKI(Public Key Infrastructure)가 바로 이에 해당한다. PKI는 기본적으로 인터넷과 같이 안전이 보장되지 않은 공중망 사용자들이 신뢰할 수 있 는 기관에서 부여된 한 쌍의 공개키와 개인키를 사용함으로써, 안전하고 은밀하게 데이터 나 자금을 교환할 수 있게 해준다. PKI는 한 개인이나 기관을 식별할 수 있는 디지털 인증 서와 인증서를 저장했다가 필요할 때 쓸 수 있는 디렉토리 서비스를 제공한다. 비록 PKI 의 구성 요소들이 일반적으로 알려져 있지만, 공급자 별로 많은 수의 서로 다른 접근방식 이나 서비스들이 생겨나고 있으며, 그 동안에도 PKI를 위한 인터넷 표준은 계속해서 진행 되어 왔다.

PKI는 인터넷 상에서 메시지 송신자를 인증하거나 메시지를 암호화하는데 있어 가장 보 편적인 방법인 공개키 암호문을 사용한다. 전통적인 암호문은 대개 메시지를 암호화하고 해독하는데 사용되는 비밀키를 만들고, 또 공유하는 일들이 관여된다. 이러한 비밀키나 개인키 시스템은 해당 키가 의도하지 않은 사용자에게 습득될 경우, 메시지가 쉽게 해독될 수 있다는 치명적인 약점을 가지고 있다. 이러한 이유 때문에 인터넷 상에서는 공개키 암 호화와 PKI 방식이 선호되고 있는 것이다. 이러한 방식은 DB 암호화에 다소 적용하기에 까다로운 절차가 요구된다.


3) 해싱 알고리즘

해싱 알고리즘(Hashing Algorithm)의 경우 데이터를 암호화하는 것이 아니라 단방향의 데이터를 안전하게 저장하고 무결성을 보장하는데 사용한다. 지문인식을 생각하면 매우 간단한데, 지문인식의 경우 고정길이의 해시값을 두고 원본데이터의 블록을 해싱하면 고 유값이 나오게된다. 즉, 원래 데이터 값을 복원하는 것이 아니라 새로운 데이터가 입력이 되면 해싱 알고리즘을 이용하여 동일한가를 판단하는 것이다.

해싱 알고리즘은 패스워드를 저장할 때 흔히 사용되는데 패스워드를 저장할 때 해싱알고리 즘을 적용하면 원본 패스워드는 복원이 불가능하지만 새로운 패스워드 입력이 도달 했을 때 일치하는가를 판단하는 것이다. 보편적인 해싱 알고리즘으로는 MD5와 SHA-1이 널리 사용되고 있으며, 해싱 알고리즘은 키가 필요하지 않고 키 길이 역시 고려 대상이 아니다.


출처 : http://www.dbguide.net/db.db?cmd=view&boardUid=152809&boardConfigUid=9&categoryUid=216&boardIdx=147&boardStep=1

Trackbacks 0 / Comments 0

HSM이란(하드웨어 암호화 키 관리 장비) - 오픈백과 인용

작성자 : 아이마켓코리아 아이마켓코리아 / 날짜 : 2014.05.12 17:17 / 카테고리 : nCipher HSM (Thales-HSM )

HSM : 하드웨어 보안 모듈 (Hardware Security Module, HSM)






암호알고리즘의 안전성

1. 안전한 설계

    - 충분한 분석 설계를 통한 안전한 암호 알고리즘의 설계

2. 안전한 사용

    - 사용자의 부주의 등으로 인한 키 노출 및 사용권한 도용 방지

    ※ 암호 알고리즘의 안전도는 키 관리에 의해 좌우됨. 아무리 안전하게 설계된 암호라 할지라도 키가 유출되면, 해당 키로 암호화된 자료는 모두 공개되어 버림.


암호알고리즘에 대한 공격

1. 학문적 분석

    - 알고리즘을 분석하여 패턴이나 약점을 찾아 공격

    - 많은 시간과 노력(학문적 바탕)이 필요

    - 이렇게 공격된 암호 알고리즘은 사용 불가

2. 암호화 키에 대한 공격

    - 사용자의 부주의 등으로 인한 암호화 키의 노출

    - 노출된 키를 획득하여 해당 키로 암호화된 자료 열람 및 도청

    - 학문적 분석에 비해 비교적 쉽게 공격가능

 

키 관리의 중요성

1. 암호 알고리즘을 학문적 분석에 비해 비교적 쉽게 공격 가능한 방법이 바로 키에 대한 공격

2. 키가 공격되어 유출될 경우, 해당키로 암호화된 자료는 모두 공개되고, 전자서명된 경우라면, 위조된 전자서명이나 문서에 대한 변조가 가능하여 경제적, 법적 피해를 초래할 수 있음.

3. 키가 공격되어 훼손된 경우, 해당 암호화 키로 암호화된 자료는 모두 열람이 불가능하여 폐기되고, 다시 백업해야 하는 등, 기업 전반에 걸쳐 커다란 피해를 초래할 수 있고, 전자서명 생성이 불가능하여, 신원 및 문서에 대한 인증, 부인방지가 불가능함. 또한, 인증키를 다시 발급받아야 하는 번거로운 절차와 재발급을 위한 비용문제 발생.

 

키 관리 유형

1. 암호화 기능을 가진 프로그램에 하드코딩하여 관리

   - 대칭키의 경우, 오랫동안 사용할 경우, 암호문-평문 간의 관계를 통한 알고리즘 공격에 쉽게 무너질 수 있음. 따라서, 주기적으로 바꾸어 줘야 하지만, 프로그램 내에 하드코딩이 되어 있어 수정에 따르는 업무 부담이 증가. 

   - 키를 수정할 경우, 키 담당자 뿐만 아니라 소스코드를 관리하는 개발자에게까지 키가 노출되어 잠재 공격자가 필요이상으로 증가(‘잠재공격자’라 함은 어떠한 정보에 대한 접근이 가능하여 이를 조직의 이익에 반하여 사용할 수 있는 사람)

 

2. 암호화하여 파일 시스템에서 관리

- 키 저장 시엔 암호화되어 보관되기 때문에 키 파일만으로는 키의 내용 해독이 불가능하지만, 실제 키가 사용될 때에는 서버의 메모리로 암호가 풀린 평문형태의 키가 로딩됨.

- 이 때, 공격자가 서버의 메모리의 내용을 덤프 등의 시도로 키를 찾으면 노출될 가능성이 있음.

- 서버의 파일에 접근할 수 있는 권한이 있으면서, 해당 업무엔 관련되지 않은 시스템관리자에 의해 업무에 대한 인식 부족으로 인한 키 파일의 손상이 예상됨.

- 키파일이 삭제되어 버리면, 해당 키를 사용하는 업무는 마비됨.

 

서버와 별개의 하드웨어에서 암호관련 작업처리 -> HSM

1. 물리적 보안

- FIPS 140-2 Level2 혹은 Level3의 보안 수준을 만족하는 물리적 보안 체계를 갖춘 HSM내에서 암호관련 연산 처리

2. 접근 제어

- 서버와 HSM과의 인증, 사용자와 HSM과의 인증을 통해 키에 대한 접근 제어

3. 안전한 메모리 및 전용 CPU

- HSM은 안전한 메모리를 탑재하여, 그 안에서 키를 보관하고 관리

- HSM은 전용 CPU를 통해 암호키 혹은 전자서명 키를 사용하는 작업은 전적으로 처리

4. 안전한 백업

- 실제 사용되는 키는 안전한 메모리에 저장되어 관리되므로 외부로 키가 유출되는 것을 막을 수 있지만, 백업되는 키에 대한 보호까지도 생각해야 함.

- HSM 내부의 유일한 모듈키와 기타 스마트카드 등의 부가 정보를 통해 백업되는 키를 HSM에서만 확인하고 사용할 수 있도록 관리


Trackbacks 0 / Comments 0

암호화 키 관리방안

작성자 : 아이마켓코리아 아이마켓코리아 / 날짜 : 2014.05.12 17:01 / 카테고리 : nCipher HSM (Thales-HSM )



암호화 키 관리방안



키 관리는 지속적인 비용과 노력이 가장 많이 요구되는 분야입니다.

암호화 키 관리를 올바르게 하지 않으면 데이터 암호화 전체가 위험해지고, 암호화 키의 교체, 삭제, 생성과 같은 민감한 작업의 보안이 취약해져서 비즈니스에 큰 영향을 미칠 수 있습니다.

따라서 암호화 키는 안전하게 보호되어야 합니다.


데이터 공격에 대한 시도가 점점 대형화, 지능화, 다양화 되어가고 있기 때문에, 데이터 보안을 위해서는 전통적인 경계 보안 솔루션(방화벽, 침입탐지, 접근제어 등) 분만 아니라 데이터 자체에 대한 암호화 솔루션이 반드시 도입되야 합니다. 그리고 암호화 솔루션에서 가장 중요한 것은 암호화 키에 대한 안전한 관리입니다.


표준 보안 알고리즘 (ex. AES)를 적용해 암호화한 데이터를 해커가 암호화 키 없이 풀어내는 것은 현재의 기술로는 불가능합니다.

즉, 암호화 키만 안전하게 관리 된다면 암호회된 데이터가 유출되어도 원래의 정보들은 유출되지 않습니다. 그러나 반대로 암호화된 데이터가 모두 유출된다면 암호화는 무용지물이 됩니다.




1. 키 관리가 적용되지 않는 암호화 시스템

키 관리의 가장 중요한 원칙은 암호화키와 암호화 데이터를 분리해서 보관해야 한다는 것입니다.

일부 보안 관리자들은 관리의 번거로움 때문에 암호화 키를 DB서버에 같이 두는 경우가 있습니다. 이것은 자물쇠 바로 옆에 열쇠를 같이 놓아두는 격으로, 암호화 키와 데이터를 동시에 유출시키려는 공격에 매우 취약합니다.


2. 키 관리가 적용된 암호화 시스템

데이터 보안에 대한 인식이 제고되면서 많은 보안 관리자들이 키를 분리하는 것에 대한 필요성을 느끼고 별도의 키 관리 서버를 사용하는 경우가 늘어나고 있다. 하지만 이 경우에도 아래의 사항들을 고려하지 않는 다면 여전히 데이터 유출의 위험으로부터 자유로울 수 없습니다.


가. 암호화 키는 절대로 키 관리 서버를 떠나서는 안됩니다.

암호화 키는 데이터 암호화에 사용되는 키와 키 자체를 암호화 하는 마스터키 모두 DB서버의 파이시스템은 물론 메모리에도 존재하지 않아야 합니다. 

해커가 DB서버를 완전히 장악하는 경우에는 메모리상에 존재하는 암호화 키도 유출될 수 있기 때문입니다.

해결책은 암호화 키가 키 관리 서버 외부로 이동(Export)하지 않으면서도 DB서버에서 암복호화 작업이 가능한 전용 하드웨어 어플라이언스 형태의 키 관리 솔루션을 사용하는 것입니다.


나. 암호화 키는 외부 공격으로부터 키를 안전하게 보호할 수 있는 곳에 보관돼야 합니다.

키를 분리에서 키 관리 서버에 보관하더라도, 해커가 DB서버를 경유해서 키 관리 서버 자체를 공격할 가능성에도 대비해야 합니다. 

이 때 키관리 서버가 범용 서버(Windows, Linux, Unix)에 키 관리 소프트웨어를 설치/운영하는 형태라면 범용 OS의 보안 취약점을 통해 공격 당할 수 있습니다.

따라서 키를 안전하게 보호하기 위해 설계된 전용하드웨어 어플라이언스에 키를 보관하는 것이 더욱 안전합니다. 국제 보안인증(FIPS, CC)  획득 여부도 키 관리 서버의 안전성을 판단하는 추가 지표가 될 수 있습니다.


다. DB관리자와 데이터 보안 관리자(암호화 키 관리자) 계쩡은 반드시 분리해서 관리해야 합니다.

DB관리자가 데이터 보안 관리자 권한까지 같이 있는 경우, 해커가 DB관리자 계정을 탈취하면 암호화 키에 대한 접근 권한까지 같이 획득하게 돼 데이터에 대한 복호화가 가능해 집니다.

따라서 DB관리자와 데이터 보안 관리자를 별도의 계정으로 관리해, DB관리자라 하더라도 암호화된 데이터의 원래 내용을 볼 수 없도록 권한을 제한해야 합니다.

키 관리는 지속적인 비용과 노력이 가장 많이 요구되는 분야입니다. 암호화 키 관리를 올바르게 하지 않으면 데이터 암호화 전체가 위험해 지고, 암호화 키의 지속적인 교체, 삭제, 생성과 같은 민감한 작업의 보안이 취약해져서 비즈니스에 큰 영향을 미칠 수 있습니다.

이들 세가지 사항에 유의해 암호화 키는 안전하게 보호돼야 합니다.

Trackbacks 0 / Comments 0

Blog Information

아이마켓코리아

보안솔루션, HSM, 인증보안, DLP 솔루션, 암호화 장비, 기업서버 판매, 보메트릭, 센스톤, 다크트레이스

공지사항

블로그 검색

Calendar

«   2019/09   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

방문자 통계

  • 전체 : 366,854
  • 오늘 : 12
  • 어제 : 331
(주) 아이마켓코리아
주소 : 서울시 강남구 삼성로 512 삼성동빌딩 16층
대표이사 : 남인봉 | 사업자등록번호 : 104-81-58502
TEL : 02-3708-8254 | Mail : raykim7@imarketkorea.com
Copyright © imarketkorea.Co,Ltd All Rights Reserved.