A. 주민번호를 예를 들면, 13자리의 숫자로 이루어진 의미를 지닌 정보에 해당 됩니다.  하지만 이 컬럼을 AES나 ARIA등의 알고리즘으로 암호화 하게 되면 16Byte 또는 20Byte (초기  벡터 적용 시) 의 아무 의미 없는 문자열로 바뀌게 됩니다.  한편 Index는 해당 컬럼의 데이터들을 Row_ID 순서와 관계없이 그 데이터만 가지고 Sorting 하여  저장하고 있고, 덕분에 Full Table Scan 없이 빠르게 검색이 가능 하도록 해 줍니다.

  여기에 암호화로 인해 순서가 뒤죽박죽이 된 데이터로 대체되게 되면 DB의 Optimizer가 Index Scan 대신에 Full Table Scan을 계획하기 때문 입니다.  CubeOne의 경우는 순서(Ordering)가 유지되는 알고리즘으로 Index를 암호화 함으로써 색인  검색이 가능한 것 입니다.

A. 흔히들 DB를 암호화한 경우에 암.복호 처리 부하를 생각하기 쉽습니다.

   이 암.복호 부하가 분명히 존재하기는 하지만 최근의 CPU 파워에서는 아주 미미한 정도 입니다.    이것 보다는 색인검색을 지원할 수가 없어서 Full Table Scan이 유발되는 것이 주된 요인 입니다.  CubeOne은 특허 기술인 Advanced Indexing 기술을 이용하여 암호화된 테이블과 Index를 이용 하여 색인검색이 가능한 유일한 제품 입니다.

A. CubeOne은 ‘암호화된 컬럼과 암호화된 컬럼’, ‘암호화된 컬럼과 일반 컬럼’과의 Join 검색 시

    Index를 이용한 자유로운 색인검색이 이루어 집니다.

A. CubeOne의 경우는 일반적인 방법으로 하시면 됩니다.

A.  암호화한 테이블에 대한 컬럼 추가/삭제 등의 작업이 필요한 경우, 반드시 CubeOne Manager를  이용하여 작업 하여야 합니다.

   SQL*Plus 또는 DB툴을 이용하여 작업하게 되면 정상적으로 작동하지 않습니다.

A. 완벽히 지원 됩니다.

    RAC구성 에서의 관건은 동일한 테이블을 여러 노드에서 공유하게 되므로 특정 암호화된 컬럼의 암.복호 키를 구성 노드들이 공유할 수 있어야 합니다.

    CubeOne은 이를 위해 키 분배 시스템을 가지고 있어서 안전한 상태로 키를 관리할 수 있습 니다. (DB 테이블이나 파일에 키를 저장하지 않습니다.)

    현재 하이플러스카드㈜를 비롯한 여러 사이트의 RAC DB를 CubeOne으로 암호화하여 운영 중 입니다.

A.  CubeOne의 장점 중 하나가 바로 이러한 구축 대상에 대한 제약사항이 거의 없다는 것입니다.

    따라서 주민번호, 계좌번호, 이름 등 이러한 용도로 사용될 수 있는 데이터 들에 대해서 아무런

    제약 없이 암호화가 가능하고, 암호화된 Index를 통한 색인검색이 최대 장점 입니다.

    현재 거의 모든 사이트들이 이런 제약 없이 주민번호가 암호화되어 운영 중입니다.

A. 블록 암호알고리즘은 16Byte단위로 암호화 되는데, 동일한 데이터(가령 이름)가 여러 개 있는 경우 IV를 사용하지 않고 암호화하면 모두다 똑 같이 암호화가 됨으로써 유추해석의 위험이 생기게 됩니다.

따라서 보안성을 높이기 위해 동일한 데이터라 할지라도 매번 다르게 암호화되도록 하는데 IV를 사용하게 됩니다.

그러나 일반 제품의 경우 IV를 사용하게 되면 일치 검색 조차도 불가능해지기 때문에 실제 적용할 때에는 IV를 사용하지 못하는 것이 일반적 입니다만, CubeOne의 경우는 Advanced Indexing 기능을 이용하여 IV를 사용하여 테이블과 Index 모두를 암호화한 상태에서도 색인검색이 가능 합니다.

A. 블록알고리즘을 적용하여 암호화시 원본 데이타 길이에 따리 16Byte 단위로 늘어나게 됩니다. 

A. CubeOne은 그렇지 않습니다.

   구축이 완료되기 전까지는 원본테이블이 그대로 사용되어지고 있으므로, 구축하는 CubeOne의

   프로세스를 종료하고 만들어지고 있는 암호화된 테이블만 삭제하면 간편하게 완료 됩니다.

   이것은 CubeOne만이 가진 무 중단 구축 구조 때문에 가능 합니다.