잠재적인 보안 위협이 발생하지 않도록 DIVAnet 작동 고객은 시스템 인증 및 권한 부여를 고려해야 합니다.
이러한 보안 위협은 적절한 구성 및 부록 A의 설치 후 점검 목록을 준수하여 최소화할 수 있습니다.
보안 위협으로부터 보호하는 중요 보안 기능은 다음과 같습니다.
인증 - 권한이 부여된 개인만 시스템 및 데이터에 액세스할 수 있도록 합니다.
권한 부여 - 시스템 권한 및 데이터에 대한 액세스 제어입니다. 이 기능은 인증을 기반으로 사용자가 적절한 액세스 권한만 가지도록 합니다.
DIVAnet 서비스는 여러 방법을 사용하여 인증을 수행할 수 있습니다.
SSL/TLS 인증서 - DIVAnet이 원격 DIVAnet 서비스에 대한 아웃바운드 연결을 만들 때 DIVAnet은 인증서 보안 저장소를 질의합니다. 이 방법은 DIVAnet이 올바른 DIVAnet 서비스에 연결되는지 확인하는 데 도움이 됩니다. DIVAnet ClientAdapter에서 DIVArchive 인스턴스로 보안 연결을 만들려면 WebServices로 식별된 ConnectionType을 사용하여 ManagerAdapter를 통해 연결해야 합니다.
액세스 규칙 - 기술적으로는 액세스 제어의 형식이지만 액세스 규칙은 인바운드 IP 주소를 기준으로 인바운드 연결을 필터링할 수 있습니다. 이 기능은 승인된 시스템만 DIVAnet 서비스에 대한 적절한 액세스 권한을 가지도록 하는 데 필요합니다.
경고:
DIVAnet 서비스는 데이터베이스 암호를 구성의 일부로 사용합니다. 암호는 설치 후 즉시 그리고 이후 최소 180일마다 변경해야 합니다. 암호를 변경한 후에는 오라클 고객지원센터에서 필요한 경우 사용할 수 있는 안전한 오프라인 위치에 저장해 두어야 합니다.
액세스 규칙은 특정 사용자나 시스템이 분산된 아카이브 시스템에서 수행할 수 있는 작업을 제한하기 위해 만들 수 있습니다. 액세스 규칙은 다음 방식으로 실행할 수 있습니다.
ClientAdapter/MultiDiva 모드 - 실행할 수 있는 DIVAnet 요청의 유형을 제한합니다.
ManagerAdapter - DIVAnet 요청(원격 시스템의 요청 등)을 충족하기 위해 실행할 수 있는 DIVArchive 요청의 유형을 제한합니다.
액세스 규칙은 DIVAnetUI 또는 API 소켓 연결(MAM 또는 자동화 시스템에서 시작 등)에서 시작된 요청에 영향을 줄 수 있습니다.
DIVAnet 요청에는 DIVAnet 레벨 또는 DIVArchive 레벨에서 실행되는 액세스 규칙이 있을 수 있습니다. DIVAnet 레벨의 경우, ClientAdapter는 요청이 수신된 위치에서 요청을 처리합니다. DIVArchive 레벨의 경우, 원격 ManagerAdapter는 DIVAnet 요청을 충족하기 위해 실행된 DIVArchive 요청을 처리합니다.
Oracle은 응용 프로그램 요구사항을 충족하는 가장 엄격한 규칙 세트를 만들 것을 권장합니다. 예를 들어, 관리자만 전역 삭제를 수행해야 하는 경우 다른 사람은 이 기능에 대한 액세스가 거부되도록 합니다. 시스템 사용자 그룹이 제한된 소스 및 대상 목록에만 액세스가 필요한 경우 사용자들이 해당하는 특정 소스 및 대상에 대해서만 요청을 실행할 수 있도록 합니다.
또한 요청을 충족하는 데 사용되는 사이트를 고려합니다. 예를 들어, 로컬 사이트의 사용자가 소스 또는 대상 사이트가 로컬 사이트가 아닌 위치에서 복사를 수행할 이유가 없다면(DIVAnet을 사용하여 가능), ClientAdapter 구성에서 이러한 규칙을 구성합니다.
마지막으로, 전체적으로 제외시킬 요청에서 특정 구성을 고려합니다. 예를 들어, 범주 없이 객체 이름만 있는 객체를 지정할 필요가 없는 경우 범주가 비어 있는 모든 요청을 제외시킵니다.
또한 각 ClientAdapter WorkflowProfile에는 WorkflowProfile에 지정된 요청에서 처리할 수 있는 유효한 메시지 목록이 포함되어 있습니다. MultiDiva 모드의 경우, 정보 메시지를 포함하여 특정 메시지가 처리되지 않도록 제외할 수 있는 방법을 제공합니다.
Oracle은 고유한 액세스 규칙을 정의하지 않더라도 AccessRules.xml.ini 파일에 정의된 기본 규칙부터 시작할 것을 권장합니다. DIVAnet 액세스 제어 기능에 대한 자세한 내용은 다음 사이트에서 제공하는 Oracle DIVAnet 설치, 구성 및 작업 설명서를 참조하십시오.
SSL/TLS 구성DIVAnet에는 로컬 시스템에서 호스트되는 웹 서비스에 사용되는 개인 키 저장소 및 원격으로 호출되는 웹 서비스를 확인하는 데 사용되는 공개 키 저장소의 두 위치에 인증서 데이터가 있습니다. Java Keytool 유틸리티를 사용하여 키 저장소 암호를 변경하고 인증서를 추가 및 삭제할 수 있습니다.
키 저장소 만들기에 대한 자세한 내용은 다음을 참조하십시오.
http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#CreateKeystore
DIVAnet 웹 서비스 연결만 SSL/TLS를 사용합니다. 이 릴리스에서 DIVArchive API 소켓 연결을 사용한 DIVArchive 또는 DIVAnet 연결은 SSL/TLS를 사용하지 않습니다.
DIVAnet 개인 키 인증서 데이터가 저장되는 위치:
$DIVANET_HOME/Program/divanet/lib/diva129.jks
정확하게 하나의 인증서만 이 키 저장소에 나타나야 합니다. 이 인증서는 이 $DIVANET_HOME 디렉토리에서 실행 중인 서비스에서 호스트하는 웹 서비스에 사용됩니다. 제공된 인증서를 새 인증서로 교체하고, 네트워크의 각 DIVAnet 사이트에 대해 서로 다른 인증서를 사용할 것을 권장합니다.
이 키 저장소의 암호를 변경해야 합니다. 암호 정보를 $DIVANET_HOME/Program/divanet/lib/diva129.properties라는 새 파일에 저장하고, DIVAnet 서비스(Linux의 경우 divanetsvc 사용자)에서는 이 파일을 읽을 수 있지만 시스템의 일반 사용자(예: Linux의 경우 diva 사용자)는 읽을 수 없도록 합니다. 파일에 대해 다음 형식을 사용합니다.
keystorePassword=newpassword
보안 저장소라고도 하는 이 데이터는 다음 위치에 있습니다.
$DIVANET_HOME/Java/lib/security/cacerts2
이 인증서 데이터는 아웃바운드 웹 서비스 호출(DIVAnetUI 포함)에서 사용됩니다. 여러 공개 키를 이 키 저장소에 로드할 수 있습니다.
새 자체 서명된 인증서를 DIVAnet 개인 키 저장소에 추가한 경우 keytool 유틸리티를 사용하여 인증서를 내보냅니다. 그런 다음 이 사이트에서 WebServices를 호출하는 모든 응용 프로그램(DIVAnet 서비스, DIVAnetUI 등)은 내보낸 인증서를 고유의 공개 키 저장소에 추가해야 합니다.