오라클에서 제공해주는 패키지가 성능상 더 유리한걸로 압니다.

(예를 들어  암호화된 컬럼에 인덱스가 필요할 경우)

답변이라기 보다는 저두 좀 궁금한 부분이 있어서 글을 올립니다.

1. "DB 암호화 솔류선 업체에서는 별도의 툴을 써야 문제가 없다고 하는데..."
   업체쪽에 근기를 문의하면 어떨까요?(공유해주시면 감사요)

2. DB 제공 모듈을 사용하면 생각해본 단점은..
   - DB에서 복호화가 가능해지지 않을까 라는 의구심
     즉, SQL 만으로 복호화가 다 가능해진다고 보는 관점 입니다.
   - AP에서 복화화가 불가능해지면, DB 에 많은 부담을 가지지 않을까요?
     뭔가 처리할 때마다 DB를 거쳐야만이 일이 되기 때문에...
   - DB의 암호 모듈이 업그레이드 되어졌을 때도 동일 암호체계로 갈 수 있을런지?
   - DB의 암호 모듈에 버그 또는 해킹이 발생했을 경우, DB 업체에서 책임(?)져 줄까요?

3. 기타 사항으로 흔히들 데이터 복호화가 불가능하게 만들겠다고 얘기하는데,
   그것은 불가능합니다.
   왜냐하면 차세대 개발 또는 버전 업그레이드가 있을 경우, 복호화가 반드시 필요할 듯 합니다.
 

오라클 모듈에서 자사의 특수한 암호화 알고리즘을 사용하는게 아닙니다.

AES, 3DES 같은 표준화된 방식을 사용하는겁니다. key는 128bit 이상을 사용하구요.

그리고 차세대 개발 할 때 복호화가 필요하지는 않죠. 암호화된 상태 그대로 이관하면 됩니다.

APP에서 암호화하는 것은  위험에 더 노출되기 쉬울 것 같은데요. APP를 해킹하는 것이 DB 자체를 해킹하는 것보다 쉬울 것 같습니다. 특히 요즘처럼 인터넷으로 노출된 웹서비스를 하거나 하는 경우는...

오라클 메뉴얼을 한번 읽어보시면 도움이 되실 듯...

Oracle® Database 2 Day + Security Guide
11g Release 2 (11.2)
Part Number E10575-05

1. 좋은 것을 알게 해주셔서 감사합니다.
   특히, 호환성 관련 정보 감사합니다.

2. 제 의견은 오라클의 기술이 떨어지거나, 잘 못 만들었다거나 하는 내용이 아닙니다.(제가 감히 ^^;)
   DB 암호화 기술에 대해 부정적인 의견도 아닙니다.
   다만, 사전에 검토하고 이런 위험성에도 불구하고 이런 장점이 있기 때문에
   DB 암호화로 수행한다. 라는 것이 필요하다는 의견입니다.

3. 복호화 관련
   - 오라클 암호화 모듈의 버그가 숨겨져 있거나, 또는 AES 알고리즘이 깨졌다거나,
     했을 때, 그것을 복호화해서 3DES(또는 다른) 알고리즘으로 다시 옮겨야 되는 과정이 필요하지 않을까 생각됩니다.
   - 오라클에서 타DB로 마이그레이션 할 경우에도 동일 함수를 타DB에서 제공할 수 있을지 의문입니다.
   이런 이유로 복호화가 필요하다고 생각되어집니다.

4. AP 에서 암호화를 하면 APP + DB도 같이 해킹해야해서, 좀 더 안전하지 않을까라는 역발상이 있습니다.