MySQL 암호화 및 키 관리

클라이언트 데이터를 관리하기 위해 PHP / MySQL에서 로컬 인트라넷 시스템을 개발 중입니다. 가장 좋은 방법은 입력되는 MySQL 서버에서 중요한 데이터를 암호화하는 것입니다.

그럼에도 불구하고 데이터에 쉽게 액세스 할 수 있지만이 작업을 수행하는 가장 좋은 방법은 무엇인지 명확하지 않습니다.

대답하기 어려운 질문처럼 보입니다. 키가 어디에 저장되어 있습니까? 키를 가장 잘 보호하는 방법은 무엇입니까? 키가 각 ​​사용자의 컴퓨터에 저장된 경우 컴퓨터를 악용 할 경우 어떻게 보호합니까? 키를 악용하는 경우 키를 변경하는 방법은 무엇입니까?

키를 DB에 저장하려면 어떻게 보호해야합니까? 사용자는 어떻게 액세스합니까?

정교한 암호화 된 키 설정을 처리하기위한 내장 MySQL 기능은 없습니다. 자체 PHP 및 / 또는 브라우저 측 (자바 스크립트?) 코드에서 대량의 암호화 논리를 구현해야합니다.

그러나 언급 한 우려 사항은 약간 특이합니다. 원격적인 관심사는 SQL 클라이언트 또는 원격 클라이언트 데스크톱 / 노트북 워크 스테이션의 무차별 대입 공격 (암호 추측)이라고 생각합니다. 이로 인해 언급되지 않은 다른 보안 조치가 이미 계획되어 있으며 가능한 손상 가능성을 분석 한 것으로 의심됩니다.

• 우선, 승인되지 않은 원격 클라이언트 IP의 모든 종류의 액세스로부터 MySQL / PHP 호스트를 보호하는 방화벽 규칙이 있다고 가정합니다. 내가 맞다면 손상된 사용자 워크 스테이션의 공격에 대해서만 걱정하는 것이 좋습니다.

• 또한 원격 클라이언트 호스트의 공격자가 루트 / 관리자 권한으로 에스컬레이션하거나 실제 사용자 자신의 계정을 직접 손상시킬 수있는 경우 암호화 또는 기타 보호 수단에 관계없이 해당 클라이언트의 데이터는 보호되지 않습니다. (공격자는 디스크에 저장된 위치에서 키를 읽거나 실제 사용자가 로그온 할 때 키를 스누핑하여 키로 데이터를 가져올 수 있습니다.)

이 두 가지 가정에서 시작하여 두 가지 관련 위협은 A) 무차별 암호 추측 및 B) SQL 삽입 시도라는 결론을 내릴 수 있습니다.

• 공격자가 실제 사용자의 키를 얻지 못하거나 실제 사용자의 데이터 이상에 액세스하려는 경우 실제 사용자 또는 다른 계정에 대해 무차별 로그온 자격 증명을 시도 할 수 있습니다. 이론적으로 각 계정을 특정 원격 클라이언트 IP에 고정하면 위험을 구분하는 데 도움이됩니다.
• 침입자가 실제 사용자에게 유효한 키를 얻는다면, 로그온 화면을지나 (아마도 보안 상 충분히 간단 할 수있는) 길을 따라 버그가있는 앱 코드의 부드러움이 생길 수 있습니다. 실제 사용자의 컨텍스트에서 SQL을 성공적으로 주입하면 다른 클라이언트 데이터에도 액세스 할 수 있습니다.

이제 서버 측 암호화가 이러한 상황에 어떻게 적용되는지에 대해 이야기하겠습니다.

• 서버 측 암호화는 SQL 인젝션 위협에 확실히 도움이됩니다. 행 값이 DB 테이블에서 암호화되면 공격자는 다른 계정에 속한 데이터의 횡설수설 암호 만 볼 수 있습니다. 위협은 격리되어 있습니다.
• 그러나 암호 추측을 강제하는 것은 서버 측 암호화에 직면 한 공격자에게 더 이상 어렵지 않습니다. 사용자 키가 서버에 저장되어 있는지 또는 비밀번호로 즉석에서 생성되는지에 관계없이 중요한 것은 올바른 비밀번호를 가지고 있는지 여부입니다. 서버는 암호가 올바른지 확인하기 때문에 유효한 저장 키를 사용하도록 결정하거나 암호가 해당 키를 생성하기위한 올바른 입력이므로 유효한 키를 계산합니다.

반면에 클라이언트 측 암호화는 실제로 무차별 강제 암호 공격과 관련이 없습니다. 제대로 구성된 키를 무차별 강제 할 수 없습니다. 클라이언트 쪽 암호화는 기본적으로 서버 쪽 암호화와 같은 SQL 주입에 대한 보호 수준을 동일하게 유지합니다. 클라이언트는 로그온시 키를 서버에 전달하여 세션이 완료 될 때까지 사본을 메모리에 보관하여 서버에 암호화 CPU 부담을 줄입니다. 또는 클라이언트가 브라우저에서 자체적으로 암호화 / 암호 해독을 처리 할 수 ​​있습니다. 두 기술 모두 기복이 있습니다.

• 서버에 키를 전달하는 것은 코딩 및 관리가 훨씬 쉬우 며, 최적화 된 암호화 코드 (아마도 C 컴파일)로 인해 훨씬 ​​빠릅니다.
• 순수한 클라이언트 측 접근 방식은 공격자가 서버에서 루트를 얻는 경우에도 여전히 암호화 된 데이터를 읽을 수없고 읽을 수 없기 때문에 추가적인 보안을 제공합니다. 유일하게 가능한 공격 경로는 원격 클라이언트 워크 스테이션을 손상시키는 것입니다.

마지막으로, 데이터베이스의 데이터를 암호화하는 데는 몇 가지 큰 운영상의 단점이 있습니다. 암호화 된 데이터 표현은 본질적으로 임의의 패턴이므로 인덱싱, 조인 등과 같은 기본 데이터베이스 기능은 작동하지 않습니다. 클라이언트는 큰 논리 부담을 감수하고 데이터베이스 기능이 일반적으로 가져 오는 많은 이점을 잃을 수 있습니다.

ecryptfs, 액세스 제어 및 키 관리를 사용하여 MySQL 데이터베이스 및 기타 프로세스의 Linux 암호화에 대한 높은 보안 및 성능을 제공하는 ezNcrypt 를 살펴볼 수 있습니다 . 아니요. 나는 그들을 위해 일하지 않습니다.

Scytale을 사용할 수 있습니다. 최신 DBMS 및 웹 응용 프로그램을위한 NoSQL 암호화 프록시입니다. 다중받는 사람 및 그룹 암호화를 지원합니다. 강력한 RSA / AES 암호화 시스템과 함께로드됩니다. 또한 100 % 무료이며 오픈 소스입니다.

https://bitbucket.org/maximelabelle/scytale