암호화 된 필드로 MySQL 데이터베이스를 검색하는 방법

MySQL 데이터베이스 의 특정 테이블 필드 를 암호화 해야한다고 가정하십시오 . 또한 암호화 한 필드 중 일부 를 검색 해야합니다 .

어쨌든 해당 필드를 어떻게 검색합니까?

각 레코드를 단계별로 해독하는 것은 옵션이 아닙니다 . 수천 개의 레코드가 있다고 가정합니다. 각 레코드를 해독하고 각 단일 레코드가 검색과 일치하는지 확인하는 데 시간과 공간이 너무 많이 걸립니다.

업데이트 2012-09-07

새 응용 프로그램을 구현하려고하므로 데이터베이스 스키마에 추가 세부 정보를 추가해도 괜찮습니다 . 또한 현재 프로덕션에서 실행중인 응용 프로그램을 확장해야합니다. 그러나 해당 응용 프로그램의 경우에도 세부 정보를 추가해도 좋습니다.

업데이트 2012-09-08

암호화는이 질문의 핵심입니다.

일부 답변에서 제안한대로 액세스 제한은 이미 적용되어 있지만 데이터 암호화에 대한 공식 요구 사항에는 맞지 않습니다.

이 공식적인 요구 사항은 PCI ( Payment Card Industry Data Security Standard) 가 아닙니다 .

분명히 그것들은 보려고 의도되지 않았으므로 그들을 검색하는 것은 문제가 될 것입니다.

과거에 사용한 한 가지 트릭은 암호화 된 데이터를 암호화하기 전에 해시하고 색인화 된 열에 해시를 저장하는 것입니다. 물론 이것은 전체 값을 검색하는 경우에만 작동합니다. 부분 값은 동일한 해시를 갖지 않습니다.

필요한 경우 해시의 "전체 텍스트"색인을 작성하여이를 확장 할 수 있지만 실제로는 매우 복잡해질 수 있습니다.

추가

사전 공격에 대한 취약성에 대한 채팅에서 상당히 긴 토론마다 내 답변에 각주를 추가하는 것이 제안되었으므로 위의 접근 방식에 대한 잠재적 보안 위험에 대해 논의하겠습니다.

사전 공격 : 사전 공격은 누군가가 알려진 값 목록을 사전 해시하고 해시를 데이터베이스의 해시 열과 비교하는 것입니다. 일치하는 항목을 찾을 수 있으면 알려진 값이 실제로 해시되는 값일 가능성이 높습니다 (해시는 고유하지 않을 수 있으므로 명확하지는 않습니다). 이것은 일반적으로 추가되거나 앞에 붙인 임의의 "소금"으로 값을 해싱하여 해시가 사전과 일치하지 않지만 위의 답변은 검색 가능성을 잃기 때문에 소금을 사용할 수 없습니다.

이 공격은 비밀번호와 같은 것을 처리 할 때 위험합니다. 인기있는 비밀번호 해시 사전을 작성하는 경우 해당 해시 값에 대한 테이블을 빠르게 검색하고 비밀번호가있는 사용자를 식별하고 신임 정보를 효과적으로 추출하여 해당 사용자의 ID를 도용 할 수 있습니다. .

SSN, 신용 카드 번호, GUID 등과 같이 카디널리티가 높은 항목의 경우 덜 위험합니다. 그러나 저장과 관련하여 다른 위험이 있습니다 [읽기 : 법적]. 따라서 저장에 대한 조언은 없습니다. ).

그 이유는 사전 공격이 작동하려면 가능한 값과 해시의 사전을 사전 빌드해야합니다. 이론적으로 가능한 모든 SSN의 사전을 만들 수 있습니다 (모든 서식 순열이 제거되었다고 가정하면 10 억 행, 신용 카드에 대한 수십억 개의 항목). 그러나 그것은 일반적으로 사전 공격의 요점이 아닙니다. 기본적으로 모든 가치를 체계적으로 조사하는 무차별 대입 공격과 비교할 수 있습니다.

SSN을 사람과 일치시키려는 경우 특정 SSN 또는 신용 카드 번호를 찾을 수도 있습니다 . 다시 한 번 말하지만, 사전 공격의 요점은 아니지만 가능할 수 있으므로 피해야 할 위험이 있다면 내 대답은 좋은 해결책이 아닙니다.

그래서 당신은 그것을 가지고 있습니다. 모든 암호화 된 데이터와 마찬가지로 일반적으로 어떤 이유로 암호화되므로 데이터와 데이터를 보호하려는 대상을 알고 있어야합니다.

CryptDB를 살펴볼 수 있습니다 . 암호화 된 데이터를 투명하게 저장하고 쿼리 할 수있는 MySQL 및 PostgreSQL의 프론트 엔드입니다. 응용 프로그램과 데이터베이스간에 전달 될 때 데이터를 암호화 및 암호 해독하여 암호화 된 데이터에서 작동하도록 쿼리를 다시 작성합니다. 그리고 각 열의 암호화 모드를 동적으로 조정하여 응용 프로그램이 사용하는 쿼리에 필요한만큼의 정보 만 노출합니다.

CryptDB가 사용하는 다양한 암호화 방법은 다음과 같습니다.

• RND 는 완전 IND-CPA 보안 암호화 체계로, 데이터에 대한 정보를 유출하지 않으며 (존재하지 않고 가변 길이 유형의 경우 길이는 제외) 쿼리 및 저장 및 검색 만 허용합니다.

• 결정적인 RND의 변형 인 DET 은 동일한 열에있는 두 개의 동일한 값이 동일한 암호문으로 암호화되도록합니다. 양식의 등식 쿼리를 지원합니다 WHERE column = 'constant'.

• OPE , 지원 불평등과 같은 쿼리하는 순서 보존 암호화 체계 WHERE column > 'constant'.

• 암호 텍스트를 곱하여 암호화 된 값을 추가 할 수있는 부분 동질 암호화 체계 (Paillier) 인 HOM SUM()쿼리, 추가 및 증분을 지원 합니다.

• SEARCH- 양식의 키워드 검색을 지원하는 체계입니다 WHERE column LIKE '% word %'.

• 다른 열의 값을 서로 비교할 수있는 DET 및 OPE의 변형 인 JOIN 및 OPE-JOIN 평등 및 범위 조인을 각각 지원합니다.

CryptDB의 진정한 장점은 각 열의 암호화 방법을 보는 쿼리에 동적으로 적용하여 느리거나 덜 안전한 구성표가 필요한 열에 만 사용된다는 것입니다. 암호화 키를 사용자 암호에 연결하는 것과 같은 다른 유용한 기능도 있습니다.

관심이 있으시면 Popa, Redfield, Zeldovich 및 Balakrishnan의 "CryptDB : 암호화 된 쿼리 처리를 통한 기밀 보호" ( SOSP 2011 ) 의 CryptDB 웹 사이트에서 링크 된 문서를 살펴 보는 것이 좋습니다 . 또한이 백서에서는 다양한 쿼리 유형을 지원하는 데 관련된 다양한 보안 및 성능 트레이드 오프에 대해 자세히 설명합니다.

현재 답변이 요구 사항에 완전히 의문을 제기 한 이유를 이해하지 못하므로 질문으로 답변 해 드리겠습니다.

사업상의 이유는 무엇입니까? 어떤 데이터를 암호화해야하며 그 이유는 무엇입니까? PCI 준수를 찾고 있다면 에세이를 작성할 수 있습니다.

요구 사항에 대한 질문 :

• 존재 또는 존재하지 않는 결과 또는 실제 데이터를 반환해야합니까?
• LIKE '% OMG_SEKRIT %'기능이 필요합니까?
• 누가 데이터를 볼 수없고 왜?

RDBMS 보안은 일반적으로 사용자 / 역할에 의해 시행되는 권한에 따라 수행됩니다. 데이터는 일반적으로 디스크의 RDBMS에 의해 암호화되지만 열 데이터 자체는 아닙니다. 데이터를 효율적으로 저장하고 검색하도록 설계된 응용 프로그램에는 실제로 의미가 없기 때문입니다.

사용자 / 역할 / api로 제한합니다. 디스크를 암호화합니다. 더 중요한 데이터를 저장하는 경우 MySQL을 사용하는 이유를 알고 싶습니다.

나는 이것을 조사하고 귀하의 질문을 발견했습니다. "암호화 된 데이터 검색을위한 실용적인 기술"( http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf) 논문 5.4 절에 설명 된 접근 방식을 기대하고 있습니다 .

기본 요점은 암호화 된 검색 문서에 존재하는 암호화 된 키워드를 포함하는 색인을 작성하는 것입니다. 요령은 해당 키워드가있는 문서 (또는 데이터베이스)의 위치도 암호화하는 것입니다.

프로그래밍 방식으로 효율적인 솔루션은

1. 레코드 ID로 검색하는 필드에 대해서만 모든 레코드를 검색하십시오.
2. 임시 테이블로 해독
3. 해당 테이블에 대해 검색을 수행
4. ID를 사용하여 검색 기준과 일치하는 전체 레코드 (모든 필드)를 검색하십시오.
5. 그것들을 해독하고 사용자에게 돌려주십시오

요점은 1과 4가 처음에 모든 레코드의 모든 필드를 검색하고 해독하는 것보다 훨씬 작은 데이터 세트라는 것입니다.

희망이 도움이됩니다.

이것은 MYSQL의 내부 암호화 기능을 사용하여 전체 검색 기능으로 가능합니다.

예를 들면 다음과 같습니다.

!!! 단순화를 위해 MYSQL ENCODE ()를 사용하고 있습니다. MYSQL_ENCODE는 이제 다른 내부 MYSQL 기능 중 하나를 사용하여 보안 검사를 고려했습니다!

UPDATE my_table
SET field=ENCODE('my_data', 'my_password')
WHERE ID=1;

SELECT DECODE(field, 'my_password') as field FROM my_table
WHERE field LIKE 'data';

위의 의견에서 알 수 있듯이 ENCODE ()를 사용하지 말고 단순성으로 인해이 예제에서는 ENCODE 만 사용 하는 다른 암호화 함수 중 하나를 사용하십시오.

php와 같은 응용 프로그램 내 에서이 작업을 수행하는 경우 각 게이트웨이 클래스 내에 각 테이블의 암호화 된 열 목록 / 배열을 저장하여 DB 게이트웨이 또는 리포지토리 클래스 내 에서이 작업을 수행 할 수 있습니다.

class UserGateway
{
    protected $encrypted_fields = array(
        'username',
        'email'
    );

    public function get($fields, ...)
    {
        foreach ($fields as $k => $field) {
            if (in_array($field, $fields)) {
                $fields[$k] = $this->decodeSelect($field);
            }
        }

        $sql = 'SELECT '.implode(',', $fields);

        //......
    }

    protected function decodeSelect($field)
    {
        return "DECODE($field, $pass) AS $field";
    }
}

물론 이것은 매우 거칠고 안전하지 않은 코드로 프로덕션 환경에서 크게 개선되지 않아야합니다. 그러나 일반적인 아이디어를 제공하는 데 목적이 있어야합니다.

SQL에서 검색하고 부분 값이 아닌 전체 값에 대해 검색한다고 가정하면 (예 : LIKE 'value %') 검색 데이터를 캡처 할 때 데이터를 암호화 할 때 사용한 것과 동일한 알고리즘을 사용하여 해당 데이터를 암호화하고 검색하십시오.

예를 들면 다음과 같습니다.

무엇이었을 까 :

SELECT FieldA, FieldB 
FROM Table1 
WHERE FieldC = 'Value'

대신 다음과 같이 보일 수 있습니다.

SELECT FieldA, FieldB 
FROM Table1 
WHERE FieldC = 'hsk&%67ghhks83'