구성 파일 (또는 다른 표준 읽을 수있는 위치)에 사용자 이름/암호 정보를 제공하지 않고 Oracle에 JDBC 연결을 설정할 수 있습니까?JDBC를 사용하여 Oracle에 연결하기 위해 자격 증명을 저장하지 않으려면 어떻게해야합니까?
일반적으로 응용 프로그램에는 데이터베이스에 연결하는 설치 매개 변수가 포함 된 구성 파일이 있습니다. 일부 DBA는 사용자 이름과 암호가 설정 파일의 일반 텍스트로되어 있다는 사실에 문제가 있습니다.
나는이 오라클과 JDBC로 가능하다고 생각하지 않지만, 나는 몇 가지 확인이 필요 ...
가능한 타협은 설정 파일에 암호를 암호화하고 연결을 설정하기 전에 암호를 해독하는 것입니다. 물론 암호 해독 키는 동일한 구성 파일에 있어서는 안됩니다. 이렇게하면 권한이없는 사용자가 실수로 구성 파일을 여는 경우에만 해결됩니다.
프로그램의 하드 와이어 된 문자열이나 Windows 레지스트리의 항목을 포함하여 어디에서나 자격 증명을 저장할 수 있습니다. 비록 비표준적인 것을 사용한다면 그것들을 검색하는 것은 당신에게 달려 있습니다. 나는 평문이 아닌 사전 압연 된 해결책을 알지 못합니다.
Java 이외의 환경에서 완전히 알 수는 없으므로 &JDBC와 Oracle과 이야기하는 JDBC에 대해 말씀 드리겠습니다.
자바 EE 앱에 대해 이야기하고 있다면 앱 서버에서 연결 풀과 데이터 소스를 설정할 수 있어야합니다. 그런 다음 애플리케이션은 해당 수준의 연결을 처리하는 연결 풀과 대화합니다.
연결 풀 및 데이터 소스는 자격 증명을 보유하고 보호합니다.
내 지식으로는 jdbc 연결 사용자 이름/암호를 일반 텍스트로 저장해야합니다. 가능한 위험을 제한하는 한 가지 방법은 사용자의 권한을 제한하여 지정된 응용 프로그램 데이터베이스 만 사용할 수 있고 미리 정의 된 호스트에서만 사용할 수 있도록하는 것입니다. IMO를 사용하면 침입자를 매우 제한 할 수 있습니다. 그는 원래 응용 프로그램이있는 동일한 호스트의 un/pw 만 사용할 수 있으며 원래 응용 프로그램의 데이터베이스를 공격 할 수 있습니다.
암호를 일반 텍스트로 저장하는 것은 모든 표준 보안 관행을 위반하는 것입니다. –
예, 문제는 있지만이 경우 해결 방법은 무엇입니까? – kosoant
과거에 궁금해하셨습니까?
솔루션은 확실히 서버 및 네트워크 수준에서 적절한 네트워크 보안을 사용하여 시스템에 액세스 할 수있는 사람의 수를 줄이고 데이터베이스 자격 증명을 사용하면 데이터베이스 계정에만 액세스 할 수 있습니다 응용 프로그램을 실행하는 데 필요한 최소한의 권한.
속성 파일의 암호화는 침입자가 다음에 감염된 서버로 이동하게하는 데 "키 또는 패스 프레이즈를 찾지 않아도됩니다"라는 관점에서 볼 때 충분하지 않을 수 있습니다. 나는 "내 이웃이 덜 안전하므로 그로부터 훔치십시오"라는 보안에 의지하지 않을 것입니다!
JDBC 클라이언트가 데이터베이스 서버에서 신뢰할 수있는 알려진 중간 계층 구성 요소/서비스 (프록시)에 대해 인증서를 사용하여 인증하는 Oracle의 프록시 인증을 사용할 수 있습니다. 나는 그것을 결코 시도하지 않았다. 그래서 나는 그것이하기가 쉬운 지 모른다.
데이터베이스를 취약하게 만들기 때문에 자격 증명없이 데이터베이스에 연결할 수 있기를 원하지 않습니다.
이것은 일반적인 문제입니다. 외부 시스템에 액세스하는 데 필요한 자격 증명을 저장하려면 어떻게해야합니까? WebLogic에는이 문제를 해결하기위한 자격 증명 매퍼가 있으며, 여기에는 자격 증명 (암호화 된)이 내장 LDAP에 저장됩니다.많은 Oracle 제품은 Oracle 지갑에 자격 증명을 저장하는 자격 증명 저장소 기능을 사용합니다.
질문에 답을 제공해 주셨습니다. 필요할 때 암호를 암호화하고 해독하십시오. 분명히 3DES와 같은 대칭 암호화 알고리즘을 사용해야 해독 할 수 있습니다. 대칭 키가 추측 할 수없는 것이 아닌지 확인하십시오.
트릭은 암호화/암호화 해제에 필요한 대칭 키를 유지하는 곳입니다. OS를 통해 보안이 설정된 파일에 저장하거나 코드에 보관할 수 있지만 코드를 안전하게 유지해야합니다. 동일한 키를 생성하고 알고리즘이 합리적으로 안전하다는 기술을 사용하면 키를 생성 할 수도 있습니다.
코드를 안전하게 유지할 수 있으면 코드에 암호를 분명히 보관할 수 있습니다. 그러나 코드를 변경하지 않고도 자격 증명을 변경할 수있는 유연성이 필요합니다.
이 솔루션에도 레이어를 추가 할 수 있습니다. 해커가 2 개의 키를 발견하도록 구성 파일 (다른 키 포함)과 암호를 암호화 할 수 있습니다. PKI를 사용하는 훨씬 더 안전한 방법이 있지만 설정하기가 어렵습니다.
두 가지 주요 접근법이 있으며 두 가지 모두 시스템 설계에 중요한 영향을 미치므로 중대한 다시 작성없이 한 위치에서 다른 위치로 쉽게 이동할 수 없습니다. 기업은 보안 거버넌스 정책을 선택하기 전에 무엇을 이해해야합니다.
1) 모든 사용자는 응용 프로그램에서 사용중인 서비스에 대해 응용 프로그램을 통해 전달되는 자격 증명이 있어야합니다. 귀하의 경우 오라클 데이터베이스는 이러한 사용자 자격 증명을 사용하여 데이터베이스에 연결합니다. 단점은 모든 사용자가 각 보안 서비스에 대한 자격 증명이 필요하다는 것입니다. 이는 합리적인 보안 접근 방식이지만 사용자 자격 증명을 제공하고 유지 관리하는 데 필요한 추가 작업이 필요합니다. 데이터베이스 관리자는 사용자의 자격 증명을 적극적으로 관리해야하며 회사의 보안 관리 정책에 따라 실행될 수 있습니다.
2) 응용 프로그램 데이터베이스 자격 증명은 안전한 디렉터리 서비스에 저장됩니다. 보안 LDAP. 응용 프로그램은 사용자의 자격 증명을 사용하여 디렉터리 서비스에 액세스합니다. 디렉터리 서비스는 액세스중인 서비스에 대한 적절한 자격 증명을 반환합니다.
두 경우 모두 적절한 작업 만 수행하려면 데이터베이스 자격 증명을 제한해야합니다. 자격 증명은 비즈니스 프로세스의 요구 사항을 반영해야합니다 (예 : 정의 된 뷰/테이블에서 선택을 허용하고, 다른 뷰에 삽입 할 수는 있지만 테이블을 작성, 업데이트 또는 삭제할 수는 없습니다. 두 번째 접근법에서는 각 주요 비즈니스 프로세스에 대해 별도의 자격 증명을 사용합니다 (예 : 주문 처리, 회계, HR 등
그러나 누군가가 응용 프로그램에 액세스하기 위해 레이어를 벗겨 내면 보안이 양파의 레이어와 같아서 DB 연결 풀 설정 파일에 액세스 할 수 있습니다. 그들은 아마도 사용자의 자격 증명을 캡처하기 위해 응용 프로그램을 트로이 목마 할 수 있습니다. 여기가 좋은 보안 거버넌스 정책이 적용되는 곳입니다.
보안 거버넌스는 실제 플랫폼에 대해이 보안 수준이 필요한 경우 비용이 많이 드는 고위 관리 약속이 필요한 복잡한 문제입니다. 전개 책임, 운영 & 사용자 권한 관리 조작을 분리해야합니다. 변경 사항을 볼 수있는 모든 권한이 있지만 구성을 변경할 수있는 권한이없는 보안 감사원이 필요할 수도 있습니다. 그것은 단순하고 유료화 된 전문성과는 거리가 멀다.
컨텍스트에서이 설명은 회사의 비즈니스 사용자와 같이 Oracle 데이터베이스와 직접적으로 개인적으로 상호 작용할 개별 사용자 커뮤니티를 가정합니다. 이는 웹 기반 응용 프로그램 (응용 프로그램 또는 웹 서버가 항상 동일한 자격 증명을 사용하여 데이터베이스에 연결하고 보안 문제가 응용 프로그램 코드를 통해 처리되는 웹 기반 응용 프로그램의 일반적인 패러다임과 대조적 인 것입니다. , 데이터베이스 수준의 액세스 제어가 아닙니다. –
프록시 인증을 살펴 보시기 바랍니다. 이 내용은 Oracle® Database Security Guide과 Oracle® Database JDBC Developer's Guide and Reference에 설명되어 있습니다.기본적으로이 작업을 수행 할 수있는 권한은 데이터베이스에 연결 권한이있는 사용자 만 있어야합니다. 사용자 실제 데이터베이스 계정은 프록시 사용자로 연결할 수 있도록 구성됩니다. JDBC를 통해 연결하는 응용 프로그램은 프록시 사용자 이름과 암호를 저장하고 연결시 이러한 자격 증명을 제공하며 연결 문자열에서 실제 데이터베이스 사용자의 사용자 이름을 더합니다. Oracle은 프록시 사용자로 연결 한 후 실제 사용자의 데이터베이스 권한을 상속받은 실제 데이터베이스 사용자를 모방합니다.
이 방법으로 보안을 악화시키지 않습니까? 프록시 사용자 이름 + 암호를 알고있는 침입자는 실제 계정으로 데이터베이스에 액세스 할 수 있습니다. 그래서 나는 프록시 인증을 위해 username + password 대신에 (OS에 의해 안전하게 관리되는) 인증서를 사용하도록 제안했다. – Alexander
여전히 프록시 사용자 이름과 암호를 보호해야합니다. 하지만 사용자가 할 수있는 것은 중간 계층이 연결할 수있는 사용자와 중간 계층이 사용자에게 맡길 수있는 역할을 제어하는 것입니다. –
정보 주셔서 감사합니다! 나는이 기능을 직접 사용하지 않았다. JDBC 계층이 OS 관리 인증서에 안전하게 액세스 할 수 있는지 여부를 알 수 있습니까? 이것이 가능하다면, 인증서가 기계에 집착 할 것이기 때문에이 방법은 프록시 사용자 이름 + 암호보다 낫습니다. – Alexander
OS 사용자의 자격 증명을 사용하고 외부에서 식별 된대로 OS 사용자를 데이터베이스에 추가 할 수있는 Kerberos를 사용해 볼 수 있습니다. Kerberos를 사용하고 심각한 보안 문제가있는 이전 방법이 아닌지 확인하십시오.
Kerberos를 지원하려면 고급 보안 옵션과 최신 JDBC 드라이버 (11g 버전)가 필요합니다. Java에서 작동 시키려면 Sql * Plus에서 사용자 이름과 빈 암호로 '/'를 사용하십시오. "이중에서 사용자 선택"은 user @ domain을 제공해야합니다. Kerberos 구성의 경우 thin 또는 OCI 드라이버를 사용하는 것과 근본적인 차이가 있음을 발견 할 수도 있습니다.
모든 J2EE 용기 (JBOSS, 톰캣, BEA) 연결 풀을 가지고있다. 그들은 여러 연결을 열어서 살아있게하고, 처음부터 새로 만드는 데 걸리는 시간은 1/100th입니다.
또한 멋진 기능이 있습니다 (예 : JBOSS). 모든 연결 정보는 외부 파일에 저장됩니다. 당신이 즉, 연결 정보를 변경하는 경우, 당신은 생산, 응용 프로그램이 동적으로 좋은 소식은 당신이를 실행할 필요가 없습니다 것입니다 새 풀
의 연결을 공급한다 DB에 테스트 전환 풀 J2EE 컨테이너 만 연결 풀링을 사용합니다. 외부 자원을 사용하면 암호를 일반 텍스트로 저장하거나 의사 암호화 할 수 있습니다. Tomcat의 내장 연결 풀링 아파치 몬즈 DBCP 표시 사용에 대한 가이드
:
이미 언급 된 해법에 부가(Kerberos 인증 프록시 인증을 사용) JDBC thin 드라이버와 함께 작동하는 다른 두 가지 솔루션이 있습니다.
그러면 연결 풀 인증 방법은 어떻게됩니까? 그렇지 않으면 근본적으로 보안이 없습니다. 오라클 계정에도 암호가 없을 수 있습니다. –