JDBC를 사용하여 Oracle에 연결하기 위해 자격 증명 저장을 피하는 방법은 무엇입니까?
구성 파일(또는 다른 표준 읽기 위치)에서 사용자 이름/암호 정보를 제공하지 않고 Oracle에 대한 JDBC 연결을 설정할 수 있습니까?
일반적으로 응용프로그램에는 데이터베이스에 연결하기 위한 설정 매개변수가 포함된 구성 파일이 있습니다.일부 DBA는 구성 파일에서 사용자 이름과 암호가 일반 텍스트로 표시되는 것에 문제가 있습니다.
오라클과 JDBC에서는 불가능할 것 같습니다만, 확인이 필요합니다...
연결을 설정하기 전에 구성 파일의 암호를 암호화하고 암호를 해독할 수 있습니다.물론 암호 해독 키가 동일한 구성 파일에 있으면 안 됩니다.이렇게 하면 권한 없는 사용자가 구성 파일을 실수로 열 때만 문제가 해결됩니다.
외부에서 식별된 대로 OS 사용자의 자격 증명을 사용하고 데이터베이스에 OS 사용자를 추가할 수 있는 Kerberos를 사용해 볼 수 있습니다.Kerberos를 사용해야 하며 심각한 보안 문제가 있었던 기존 방식을 사용해서는 안 됩니다.
Kerberos를 지원하려면 고급 보안 옵션과 최신 JDBC 드라이버(약 11g 버전)가 필요합니다.Java에서 사용할 수 있도록 하기 전에 '/'를 사용자 이름으로 사용하고 암호를 비운 상태에서 Sql*Plus에서 사용해 보십시오."select user from dual"은 user@domain을 제공해야 합니다.또한 Kerberos 구성과 관련하여 씬 드라이버 또는 OCI 드라이버를 사용하는 것 사이에는 근본적인 차이가 있을 수 있습니다.
자격 증명 없이는 데이터베이스에 연결할 수 없기 때문에 데이터베이스에 연결할 수 없습니다.
일반적인 문제입니다. 외부 시스템에 액세스하는 데 필요한 자격 증명을 저장하려면 어떻게 해야 합니까?WebLogic에는 이 문제를 해결하기 위한 자격 증명 매퍼가 있으며, 여기서 자격 증명(암호화된)은 내장된 LDAP에 저장됩니다.대부분의 오라클 제품은 오라클 지갑에 인증 정보를 저장하는 인증 정보 저장소 기능을 사용합니다.
질문에서, 당신은 답을 제공했습니다.암호를 암호화된 상태로 저장하고 필요할 때 암호를 해독합니다.암호를 해독하려면 3DES와 같은 대칭 암호화 알고리즘을 사용해야 합니다.대칭 키가 추측할 수 있는 키가 아닌지 확인합니다.
비결은 암호화 해제에 필요한 대칭 키를 보관하는 것입니다.OS를 통해 보호되는 파일에 넣거나 코드에 보관할 수 있지만 코드를 보호해야 합니다.또한 동일한 키를 생성하는 기술을 사용하고 알고리즘이 상당히 안전한 경우 키를 생성할 수 있습니다.
코드를 안전하게 유지할 수 있다면 암호도 코드에 유지할 수 있습니다.그러나 코드를 변경하지 않고 자격 증명을 변경할 수 있는 유연성이 필요합니다.
이 솔루션에 더 많은 계층을 추가할 수도 있습니다.구성 파일(다른 키로)과 내부 암호를 암호화하여 해커가 2개의 키를 검색하도록 할 수 있습니다.PKI를 사용하는 훨씬 더 안전한 다른 방법들이 있지만, 그것들은 설정하기가 어려워집니다.
프록시 인증에 대해 알아보시는 것이 좋습니다.이 내용은 Oracle® Database Security Guide와 Oracle® Database JDBC Developer's Guide and Reference에 설명되어 있습니다.기본적으로 데이터베이스에 연결 권한만 있는 사용자가 있어야 합니다.사용자 실제 데이터베이스 계정은 프록시 사용자로 연결할 수 있도록 구성됩니다.그런 다음 JDBC를 통해 연결하는 응용 프로그램이 프록시 사용자 이름과 암호를 저장하고 연결 시 이러한 자격 증명과 연결 문자열에 있는 실제 데이터베이스 사용자의 사용자 이름을 추가합니다.Oracle은 프록시 사용자로 연결한 다음 실제 데이터베이스 사용자를 모방하여 실제 사용자의 데이터베이스 권한을 상속합니다.
든모.J2EE컨테이너(JBOSS, Tomcat, BEA)에는 연결 풀이 있습니다.그들은 많은 연결을 열고, 그것들을 살아있게 하고, 당신에게 줄 것입니다.1/100th 처음부터 하나를 만드는 데 걸리는 시간.
은 또한 특징들을 , 가다게또, 그은멋특 가있지습다니고을징들진들한,다,JBOSS예를 들어, 모든 연결 정보는 외부 파일에 저장됩니다.연결 정보를 변경하는 경우(예: 테스트에서 운영 DB로 전환하면 응용 프로그램이 새 풀에서 동적으로 연결이 공급됩니다.
좋은 소식은 당신이 풀 러닝을 할 필요가 없다는 것입니다.J2EE연결 풀링을 사용하기 위한 컨테이너입니다.외부 리소스를 사용하여 암호를 일반 텍스트 또는 유사 암호화로 저장할 수 있습니다.
Tomcat의 내장 연결 풀링 사용에 대한 지침은 apache commons-dbcp:
제가 알기로는 jdbc 연결 사용자 이름/비밀번호는 일반 텍스트로 저장해야 합니다.이로 인해 발생할 수 있는 위험을 제한하는 한 가지 방법은 미리 정의된 호스트에서만 지정된 애플리케이션 데이터베이스를 사용할 수 있도록 사용자 권한을 제한하는 것입니다.IMO는 공격자를 매우 제한합니다. 공격자는 원래 응용 프로그램이 있는 동일한 호스트에서만 un/pw를 사용할 수 있고 원래 응용 프로그램의 데이터베이스를 공격할 수 있습니다.
과거에 이것이 궁금했습니다.
이 솔루션에는 서버 및 네트워크 수준에서 적절한 네트워크 보안을 유지하여 시스템에 액세스할 수 있는 사용자 수를 줄이고, 데이터베이스 자격 증명을 통해 애플리케이션 실행에 필요한 최소한의 사용 권한만 데이터베이스 계정에 액세스할 수 있도록 하는 것이 포함됩니다.
속성 파일을 암호화하면 공격자가 손상된 다음 서버로 이동할 수 있도록 "키 또는 암호 구문을 찾는 데 방해가 될 수 없습니다"라는 측면에서 충분히 억제할 수 있습니다.하지만 저는 "내 이웃은 덜 안전하니 제발 그에게서 훔치세요" 보안에 의존하지 않을 것입니다!
두 가지 주요 접근 방식이 있으며, 두 가지 모두 시스템 설계에 상당한 영향을 미치므로 중요한 재작성 없이는 시스템 간에 이동하기가 쉽지 않습니다.회사 보안 거버넌스 정책을 선택하기 전에 먼저 이해해야 합니다.
모든 사용자는 애플리케이션에서 사용 중인 서비스에 대해 애플리케이션을 통해 전달되는 자격 증명을 가지고 있습니다. 이 경우 Oracle 데이터베이스는 해당 사용자 자격 증명을 사용하여 데이터베이스에 연결합니다.단점은 모든 사용자에게 각 보안 서비스에 대한 자격 증명이 필요하다는 것입니다.이는 합리적이고 안전한 접근 방식이지만 사용자 자격 증명을 제공하고 유지하기 위해서는 상당한 추가 작업이 필요합니다.데이터베이스 관리자는 사용자 자격 증명을 적극적으로 관리해야 하며, 이는 회사의 보안 거버넌스 정책에 위배될 수 있습니다.
응용프로그램 데이터베이스 자격 증명은 보안 디렉토리 서비스(예: Secure LDAP)에 저장됩니다.응용 프로그램은 사용자의 자격 증명으로 디렉터리 서비스에 액세스합니다.디렉터리 서비스가 액세스 중인 서비스에 대한 적절한 자격 증명을 반환합니다.
두 경우 모두 데이터베이스 인증 정보는 적절한 작업만 수행하도록 제한되어야 합니다.자격 증명은 정의된 보기/테이블에서 선택하거나 다른 보기/테이블에 삽입할 수 있지만 테이블을 생성, 업데이트 또는 삭제할 수는 없습니다.두 번째 접근 방식에서는 각 주요 비즈니스 프로세스(예: 주문 처리, 회계, 인사 등)에 대해 별도의 자격 증명을 사용합니다.
그러나 보안은 애플리케이션에 액세스하기 위해 계층을 제거하여 DB 연결 풀 구성 파일에 액세스할 수 있는 경우 양파 계층과 같습니다.사용자의 자격 증명을 캡처하기 위해 응용프로그램을 트로이 목마로 처리할 수 있습니다.이것이 좋은 보안 거버넌스 정책이 필요한 부분입니다.
Security Governance는 복잡한 문제로, 라이브 플랫폼에 이러한 수준의 보안이 필요하면 비용이 발생하기 때문에 고위 관리자의 헌신이 필요합니다.개발 책임과 배포, 운영 및 사용자 권한 관리를 분리해야 합니다.또한 변경사항을 볼 수 있는 모든 액세스 권한은 있지만 구성을 변경할 수 없는 보안 감사인이 필요할 수도 있습니다.그것은 단순함과는 거리가 멀고 보수가 높은 전문성입니다.
Java 및 JDBC가 Oracle과 대화하는 것 외에 귀사의 환경에 대해 완전히 알지 못하기 때문에 이에 대해 말씀드리겠습니다.
Java EE 앱을 말하는 경우 앱 서버에서 연결 풀 및 데이터 소스를 설정할 수 있어야 합니다. 그러면 애플리케이션이 해당 수준에서 연결을 처리하는 연결 풀과 통신합니다.
연결 풀 및 데이터 원본은 자격 증명을 보유하고 보호합니다.
프로그램의 유선 연결된 문자열이나 Windows 레지스트리의 항목을 포함하여 모든 위치에 자격 증명을 저장할 수 있습니다.하지만 표준이 아닌 것을 사용하는 경우 검색하는 것은 사용자에게 달려 있습니다. 일반 텍스트가 아닌 사전 등록된 솔루션에 대해서는 잘 모릅니다.
데이터베이스 서버에서 신뢰하는 알려진 중간 계층 구성 요소/서비스(프록시)에 대해 JDBC 클라이언트가 인증서를 사용하여 인증하는 Oracle의 프록시 인증을 시도할 수 있습니다.저는 그것을 시도해 본 적이 없어서 그것이 쉬운지 모르겠습니다.
이미 언급한 솔루션(Kerberos 인증, 프록시 인증 사용) 외에도 JDBC 씬 드라이버와 함께 작동하는 두 가지 솔루션이 있습니다.
- SSO 지갑에 암호 저장: 지갑을 사용하여 사용자의 암호를 저장할 수 있습니다.SSO 지갑을 사용하면 지갑 자체에 암호가 없습니다. SSO 지갑은 SSL 환경에서 일반적으로 사용되지만 암호를 저장하는 데에도 사용될 수 있습니다.
- 사용자 인증과 함께 SSL 사용: DN(식별 이름)으로 외부에서 인증된 사용자로 SSL을 구성합니다.이 사용자는 암호가 없습니다.이 DN이 있는 인증서를 사용하여 SSL로 연결하기만 하면 이 사용자를 사용하여 세션을 만들 수 있습니다.
언급URL : https://stackoverflow.com/questions/126720/how-to-avoid-storing-credentials-to-connect-to-oracle-with-jdbc
'programing' 카테고리의 다른 글
| 장고 프레임워크의 양식 필드에서 가치를 얻는 방법은 무엇입니까? (0) | 2023.07.18 |
|---|---|
| 숫자처럼 보이는 것을 인덱싱할 때 파이썬의 "세 개의 점"은 무엇을 의미합니까? (0) | 2023.07.18 |
| HTTP 오류 429(Too Many Requests) 파이썬을 방지하는 방법 (0) | 2023.07.18 |
| Java에서 Closeable 인터페이스의 Close() 메서드의 동일성은 어떻게 보장됩니까? (0) | 2023.07.18 |
| python의 속성 파일(Java Properties와 유사) (0) | 2023.07.18 |