우리는 Java로 작성된 웹 응용 프로그램을 가지고 있으며 데이터를 PostgreSQL 데이터베이스에 저장합니다.웹 응용 프로그램의 암호화/보안
Google 데이터베이스의 일부 필드와 일부 업로드 된 문서를 암호화하고 싶습니다. 그러나 이들 모두는 양방향 암호화 (즉, 암호 해독이 가능해야 함)가되어야하며 해독은 상당히 빨라야합니다.
그러나 실제로 데이터를 암호화/해독하는 "안전한"방법을 생각해 낼 수는 없습니다. 이것은 웹 응용 프로그램이며 클라이언트가 없기 때문에 모든 암호화 키가 웹 서버 (일반 텍스트 또는 실제 코드) 또는 데이터베이스 서버에 저장됩니다.
실제로 최소한 적당히 만드는 방법에 대한 다른 아이디어 ... 안전합니까?
아니요, 없습니다. 비즈니스 계층에서 원시 (암호화되지 않은) 데이터에 액세스해야하는 경우 비즈니스 계층을 해킹 할 수있는 사용자 (예 : 애플리케이션 코드 또는 애플리케이션에서 읽을 수있는 파일에 저장된 일부 키워드를 들여다 볼 수있는 사용자)도 데이터에 액세스 할 수 있습니다. 이 내용은 related question을 참조하십시오.
응용 프로그램에서 읽을 수있는 디코딩 키를 사용하여 일부 encription을 구현하면 임시 데이터 스파이웨어 및 일부 사용자 역할 또는 사례 (예 : DB는 읽을 수 있지만 DB는 읽을 수 없음) 또는 누군가 DB를 훔친 사람 등). 하지만 그게 전부입니다.
AES는 대칭 암호화를위한 잘 정립 된 표준이며 JDK에 대한 지원이 내장되어 있으므로 사용하는 것이 좋습니다.
이제 응용 프로그램이 액세스 할 수있는 방식으로 키를 저장해야한다는 사실이 틀림 없습니다. 그러나 코드 또는 파일에 키를 저장하는 대신 내부자가 암호화를 이길 수 있도록하기 위해 "비밀을 위로"다른 물리적 위치로 나눌 수 있습니다. 예를 들어 :
개발 때, 당신의 프로그램에 새 키와 "하드 코드"를 생성합니다. 이 키를 호출하십시오.
설치시 두 번째 키를 생성하십시오. 이 키를 호출하십시오. B. 이제 키 A를 사용하여 키 B를 암호화하고 파일 시스템에 암호화 된 버전 을 저장하십시오. 서버가 실행되는 사용자에게만 파일을 읽을 수 있도록합니다.
각 신용 카드 번호 (예 : 각 신용 카드 번호)를 암호화하려면 세 번째 키를 생성하십시오. 이 키를 호출하십시오. 키를 사용하여 값을 암호화하십시오. 그런 다음 키 C를 키 B로 암호화하고 데이터베이스 내에 암호화 된 버전 을 저장합니다. (당신은 같은 테이블에 별도의 필드를 사용할 수 있습니다.)
해독하려면 데이터베이스와 파일 시스템에서 암호화 키 B에서 암호화 키 C를 읽을 것입니다. 키 A를 사용하여 키 B를 해독하고 키 B를 사용하여 키 C를 해독합니다. 그런 다음 키 C를 사용하여 값을 해독합니다.
이 모든 것이 당신을 어떻게 구입합니까? 아이디어는 비밀의 일부를 다른 여러 그룹에 분산시키는 것입니다. 이상적으로는 다른 그룹의 사람들이 관리합니다.암호화 된 값을 해독하고자하는 사람은 프로그램 코드, 파일 및 데이터베이스의 세 항목 모두에 액세스해야합니다. 이 단계를 더 진행하고 체인에 더 많은 키를 추가 할 수 있지만 아이디어를 얻을 수 있습니다.
@Rob H : 응용 프로그램을 손상 시키면 키 C가 손상되고 전체 체인을 우회하므로 보안이 유지됩니다. – Borealid
"응용 프로그램을 손상시키는"의미가 확실하지 않습니다. 소스 코드를 보는 것을 의미하는 경우, 소스 코드로 키 C를 해독 할 수 없으므로 사실이 아닙니다. –
@Rob H : 코드 삽입, 실행중인 서버에 대한 루트 액세스, 콜드 부트 공격, 사이드 채널 공개 등을 통해 응용 프로그램 제어 또는 메모리 액세스. 키 C는 응용 프로그램이 실행되는 동안 암호 해독됩니다. , 그래서 취약하다. – Borealid
실제로 좀 더 안전하게 만들 수 있습니다.
PKCS11 인터페이스와 함께 스마트 토큰을 사용하는 경우 토큰에서 키 쌍을 생성 한 다음 응용 프로그램이 시작될 때마다 암호를 수동으로 제공하여 키 쌍에 대한 액세스를 안전하게 유지 한 다음 나중에 언제든지 제거 할 수 있습니다 토큰을 제거하여 데이터를 읽을 수있는 기능. 내결함성이 필요한 경우 한 쌍의 토큰을 사용하여 이중 암호화합니다.
여기서 중요한 원칙은 개인 키가 사용할 수있는 응용 프로그램에서하지만 응용 프로그램에서하지 읽을 수 것입니다. 따라서 응용 프로그램 소스를 살펴보면 아무 것도 얻을 수 없습니다.
이 솔루션은에서 데이터를 읽는 동안 응용 프로그램 에 액세스하는 사람을 중지하지 않습니다. 그러나 당신은 그걸 막을 수 없었습니다. 그들은 암호화되기 전에 메모리에서 데이터를 읽을 수있었습니다.
이것은 올바르게 구현 된 경우 모든 형태의 오프라인 공격으로부터 사용자를 안전하게 보호합니다. 해커는 물리적으로 좋은 하드웨어 토큰을 사용할 수 없습니다. 키를 모르면 키를 추출 할 수 없습니다. 토큰이 brute-force 공격에 하드웨어 제한을 가지고 있기 때문에 암호를 추측 할 수 없습니다. 따라서 데이터를 복구 할 수있는 유일한 방법은 토큰 및을 암호로 도용하거나 데이터 암호화 키 (2048 비트 RSA 인증서 일 수 있음)를 무차별 적으로 공격하는 것입니다.
꽤 오래된 질문이지만, 기록을 위해 나는 나를 위해 확보 된 내 솔루션으로 알아 냈던 것을 설명합니다.
관리자가 계정을 만드는 동안 임의의 암호화 키를 생성합니다. 이 키는 관리자 암호를 사용하여 AES로 암호화되고 데이터베이스에 저장됩니다. 관리자 암호는 (해싱 또는 스프링 암호 엔코더에 의해) 보안됩니다. 이 단계에서는 아무도 실제 암호화 키에 액세스 할 수 없습니다.
관리자가 로그인하면 일반 암호가 제공되고 암호화 된 사용자 암호와 비교됩니다. 맞으면 암호화 암호를 해독하고 잊어 버리는 데 사용됩니다. 그런 다음 암호화 비밀번호가 세션에 보관됩니다. 이는 누군가가 서버를 해킹하고 메모리 덤프를 만들고 암호에 액세스 할 수 있지만 현재 로그인 한 사용자에 대해서만, 응용 프로그램이나 데이터베이스 만 사용하지 않는 경우에만이 메커니즘의 유일한 취약점입니다. 나는 현재 이것에 또 다른 보안 수준을 추가하려고 생각하고있다. 예를 들어 사용자 로그인 시간 등으로 메모리의 암호를 암호화한다. 그러나 어쨌든 사용자가 각 요청마다 비밀번호를 입력해야하는 경우에도 GC로 메모리에서 퇴장 한 시점을 보장 할 수 없으며 어느 시점에서이를 메모리에 보관해야합니다.
따라서 사용자 세션은 암호화 암호를 알고 있으며 암호화 및 암호 해독에 사용됩니다. 관리자가 새 사용자를 생성하면 새로운 사용자에 대한 새 비밀번호를 입력 할 때 암호화되지 않은 비밀번호에 액세스 할 수 있습니다. 생성 된 비밀번호는 db로 생성되고 보관되며이 사용자 비밀번호로 암호화됩니다.
Do 누군가가 실행중인 서버를 해킹하고 메모리를 덤프하는 것 외에이 메커니즘의 다른 취약점을 볼 수 있습니까?
예를 들어 내 대답을 참조하십시오. 그렇습니다. – Borealid
@Borealid : 그렇습니다. 대부분의 시나리오에는 방법이 없습니다 ... 실용적이지 않습니다. 예를 들어, "응용 프로그램이 시작될 때마다 수동으로 제공되는 암호"는 웹 응용 프로그램에서는 거의 실용적이지 않습니다. – leonbloy
응용 프로그램 원본 (또는 구성 파일)에 암호를 남겨두면 공격자가 실제로 토큰을 얻어야 만 공격받을 수 있습니다. 보안과 가용성 사이에는 항상 상충 관계가 있습니다. – Borealid