디비 컬럼암호화 사용안하는 이유가 궁금하고 , 개인키 대안 문의드립니다.
본문
안녕하세요?
최근에 디비 개인정보 컬럼에 대한 암호화를 알게됐는데요.
BLOB형태에 데이터를 암호화해서 넣던데요.
서버의 할당된 개인키 기반으로 암호화하면 , 서버의 직접적인 해킹 되기전까지는(개인키유출)
일반적인 인젝션같은 외부 해킹으로는 디비유출이 되도 개인정보 내역은 암호화가 되있어서 안전하지않나요? (HTTPS 전제)
쇼핑몰이라면 개인정보가 많이 들어가서 굉장히 민감한 문제로 보일텐데..
이부분이 궁금하네요.
서버 해킹으로 인한 암호화에 쓸 개인키 유출방지에 대해서도 고민중인데요.
1. 서버에 개인키 하나로 쓰는 방법 ,
2. 사용자의 임의문자열 + 서버의 개인키를 조합해서 컬럼암호화를 하는방법.
주로 암호화하는 칼럼은 회원정보의 개인정보칼럼 , 주문의 개인정보칼럼정도일텐데요.
1번경우는 어떤상황이든 복호화가 편한 장점이있지만 , 서버가 해킹당하면 키가 공개돼버려서 복호화가 쉽게 이루어지는 큰 단점이있고..
2번경우는 주문을 하더라도 주문자 본인외에는 복호화를 할수없는 큰장점을 가지고있지만..
관리자 조차도 복호화를 못한다는 문제가있는데요..
2번이 매리트가있지만 , 사용자가 임의문자열에 대한 값을 까먹으면 나중에 복호화할수없는 문제가 생길 여지도있고..
사용자의 아이디나 패스워드조합은 유추하기 쉬우니 이건 안될테고..
최선의 컬람 암호화방식은 뭐가있을까요?
1번 케이스에서 서버보안에 투자를 많이 해야할까요?
아니면 2번케이스를 좀더 보완할수있는 방법을 찾아봐야할까요?
여튼 웹로직의 쿼리에 방해가 안되는 선에서 부분 암호화처리를 해야한다는 전제가 깔리지만요.
인터넷 최근 기사를 뒤져보니 점점더 개인정보유출에 대한 법적책임이 강해지는것같은데..
그에 대응하는 수준높은 보안기술을 쓰고싶은사람도 돈문제나 기술문제로 못써서 아쉽네요.
답변 2
당연히 자동으로 암호화가 되어야 하지요.... 안그럼 운영을 할 수 없잖아요.
단지 암호화를 하는 키와 복호화를 하는 키가 서로 다르다는 것입니다.
그중 복호화를 하는 키를 관리자가 별도로 관리(메모 등 ^^;)를 해서
복호화가 필요할때만 수동으로 입력하겠다는 것이죠....
저도 잘은 몰라요...
아래는 그에 대한 참고입니다.
자세한 설명 주소 : https://javaplant.tistory.com/26
아래 간단설명 ----
--------
비대칭키(공개키)
비대칭형 암호는 이름 그대로 암호화 키와 복호화 키가 다르다. 암호화를 하면 하나의 키쌍이 생기고 이 두개의 키는 수학적으로 밀접한 관계를 가지고 있다. 두개의 키를 각각 키A, 키B라고 했을 때 키A로 암호화한 암호문은 키B로만 복호화 할수 있고 키B로 암호화한 암호문은 키A로만 복호화 할수 있다. 따라서 이중 하나의 키만 비밀로 보호하고(이를 '비밀키', '개인키'라고 한다) 다른 하나의 키는 공중에게 공개해도 관계가 없다(이를 '공개키'라고 부른다). 이렇게 둘 중 하나의 키는 반드시 공개되어야 통상적인 사용이 가능함으로 공개키 암호라고도 불린다. 공개키로 암호화한 암호문은 어차피 개인키를 가진 사람만이 풀어볼 수 있으므로 상호간에 공개키만 교환하고 상대의 공개키로 암호화를 해서 데이터를 교환하면 상대는 자신의 개인키로 복호화를 한다. 따라서 키 배송 문제는 근본적으로 발생하지 않는 것.
하지만 비대칭형 암호는 암복호화가 대칭형 암호에 비해 현저하게 느리다는 문제점이 있다. 따라서 현실적으로는 비대칭형 암호를 이용해서 대칭형 암호의 키를 배송하고 실제 암호문은 대칭형 암호를 사용하는 식으로 상호보완적으로 이용하는 것이 일반적이다. 그리고 비대칭형 암호라고 약점이 없는 것은 아니어서 중간자 공격(MITM : Man In The Middle Attack)에는 취약하다. 해커가 중간에서 통신을 가로채어 수신자에게는 송신자인 척하고 송신자에게는 수신자인 척 해서 양쪽의 공개키와 실제 암호화에 사용되는 대칭키를 모두 얻어내는 기법.
또한 개인키-공개키 관계를 역이용해서 전자서명에 활용하기도 하는데, 특정한 문서를 개인키로 암호화해서 발송하면 이 문서는 해당 발신자의 공개키로만 복호화가 가능하다. 공개키이므로 아무나 열어볼 수는 있지만 해당 발신자의 공개키로만 열린다는 사실에서 이 문서가 해당 발신자에게서 온 것이라는 사실을 인증할 수 있는 것.
어떤 방법이되었든 관리자는 복호화 할 수 있어야 하지 않나요?
그렇지 않으면 관리가 어려~불가할테니까요.
그렇다면 어떤 방식의 키가 됐든 어딘가는 키가 있어야 하고요...
그럼 서버가 털리면 끝이죠.. 동감합니다...
번거롭지만 이러면 어떨까요....
비대칭으로 인코딩을 하고...
해제키는 관리자가 외우고 있는 쪽으로 ^^;;;;;
여러명이 함께 관리한다면 이마저 어렵겠죠 ^^;
시간내주시고 좋은 정보 감사드립니다.
가입/주문의 개인정보칼럼에 동적으로 키를 생성해서 컬럼 암호화하려면
개인키를 서버에 저장을 해놔야하는건 1번케이스와 유사하지않나 생각하는데..
제가 잘몰라서 이해를 잘못한건지 몰르겠네요.
중요한점은 관리자가 수동으로 컬럼암호화를 시도하는방식이 아닌 그냥 기존 영카트 주문자동화 로
직에서 컬럼암호화를 처리해야한다는 전제입니다.
