서버를 설치하거나 업그레이드하기 전에 보안에 대해 알아야 할 사항

온라인 편집

IBM Storage Protect 서버의 향상된 보안 기능 및 환경 업데이트를 위한 요구사항에 대한 정보를 검토하십시오.

시작하기 전에

버전 8.1.2부터 IBM Storage Protect 에 더 엄격한 보안 설정을 적용하는 개선사항이 추가되었습니다. IBM Storage Protect를 설치하거나 업그레이드하기 전에 다음 단계를 완료하십시오.
  • IBM 문서의 새 소식 항목에서 보안 섹션의 정보를 검토하여 각 버전에 대한 보안 업데이트에 대해 알아보세요.
  • 사용자 환경에 이전 버전의 서버가 있는 경우 기술 노트 562939의 제한사항 및 알려진 문제를 검토하십시오. 이러한 제한사항을 피하고 최신 보안 개선사항을 이용하려면 사용자 환경의 모든 IBM Storage Protect 서버 및 백업 아카이브 클라이언트를 최신 버전으로 업데이트하도록 계획하십시오.
  • 서버를 복원하는 데 필요한 다음 디렉토리 및 파일을 백업했는지 확인하십시오.
    • 서버 옵션 파일 (dsmserv.opt)
    • 디바이스 구성 파일 (예: devconf.dat)
    • 볼륨 히스토리 파일 (예: volhist.dat)
    • 마스터 암호화 키 파일 (dsmkeydb.kdb 또는 dsmkeydb.sth)
    • 서버 인증서 및 개인 키 파일 (cert.kbd 또는 cert.sth)

보안 개선사항

V8.1.2:
TLS (TLS)를 사용하는 보안 프로토콜

V8.1.2IBM Storage Protect 또한 최신 버전의 소프트웨어는 서버, 스토리지 에이전트 및 백업 아카이브 클라이언트 간의 인증에 1.2또는 그 이후 Version을 TLS 사용하는 개선된 보안 프로토콜을 갖추고 있습니다.

V8.1.11 부터는 IBM Storage ProtectTLS1.3 프로토콜을 활성화하여 서버, 클라이언트 및 스토리지 에이전트 간의 통신을 보호할 수 있습니다. TLS 1.3을 사용하려면 통신 세션의 두 당사자가 TLS 1.3을 사용해야 합니다. 당사자 중 하나가 TLS 1.2를 사용하는 경우 두 당사자는 기본적으로 모두 TLS 1.2를 사용합니다.

SSL( SSL )의 자동 구성 및 인증서 배포
V8.1.2 이상 버전의 소프트웨어를 사용하는 서버, 스토리지 에이전트 및 클라이언트는 TLS 를 사용하여 서로 인증되도록 자동으로 구성됩니다.

새로운 프로토콜을 사용하면 각 서버, 스토리지 에이전트 및 클라이언트는 TLS 연결을 인증하고 허용하는 데 사용되는 고유한 자체 서명 인증서를 보유하게 됩니다. IBM Storage Protect 자체 서명 인증서는 엔티티 간 보안 인증을 사용하고, 데이터 전송을 위한 강력한 암호화를 사용하며, 클라이언트 노드에 공개 키를 자동으로 분배합니다. V8.1.2 이상 버전을 사용하는 모든 클라이언트, 스토리지 에이전트 및 서버 간에는 인증서가 자동으로 교환됩니다. TLS 를 수동으로 설정하거나 모든 클라이언트에 대해 인증서를 수동으로 설치할 필요가 없습니다. TLS 의 새로운 개선 사항에는 옵션 변경이 필요하지 않으며, 단일 관리자 ID로 여러 시스템에 액세스하는 경우가 아니라면 첫 연결 시 인증서가 클라이언트로 자동 전송됩니다.

기본적으로 자체 서명된 인증서가 분배되지만, 선택적으로 인증 기관에서 서명한 인증서와 같은 다른 구성을 사용할 수 있습니다. 인증서 사용에 대한 자세한 정보는 SSL (Secure Sockets Layer) 및 TLS (Transport Layer Security) 통신을 참조하십시오.

TCP/IP 와 TLS 프로토콜을 결합하여 안전한 통신을 보장하고 성능에 미치는 영향을 최소화
이전 버전의 IBM Storage Protect 소프트웨어에서는 모든 통신을 암호화하기 위해 TLS 또는 TCP/IP 중 하나를 선택해야 했습니다. 새로운 보안 프로토콜은 서버, 클라이언트 및 스토리지 에이전트 간의 통신을 보호하기 위해 TCP/IP 와 TLS 를 함께 사용합니다. 기본적으로 TLS 은 인증 및 메타데이터 암호화에만 사용되며, TCP/IP 은 데이터 전송에 사용됩니다. TLS 의 암호화 기능은 주로 인증 목적으로만 사용되므로, 백업 및 복원 작업의 성능에는 영향을 미치지 않습니다.

선택적으로, TLS 를 사용하여 클라이언트-서버 통신 시 ` SSL client` 옵션을, 서버-서버 통신 시 ` UPDATE SERVER command` 명령어의 ` SSL parameter`를 통해 데이터 전송을 암호화할 수 있습니다.

역호환성으로 인해 일괄입 (줍니다다십시오다에서으므로할 수 없습니다).
SESSIONSECURITY 매개변수가 TRANSIAL로 설정된 경우 IBM Storage Protect 서버 및 클라이언트의 업그레이드된 버전은 계속 이전 버전에 연결할 수 있습니다.

서버를 업그레이드하기 전에 백업 아카이브 클라이언트를 V8.1.2 이상으로 업데이트할 필요가 없습니다. 서버를 V8.1.2 이상으로 업그레이드한 후에는 이전 버전의 소프트웨어를 사용하는 노드 및 관리자가 엔티티가 STRICT값에 대한 요구사항을 충족할 때까지 TRANSIAL값을 사용하여 서버와 계속 통신합니다. 마찬가지로 IBM Storage Protect 서버를 업그레이드하기 전에 백업 아카이브 클라이언트를 V8.1.2 이상으로 업그레이드할 수 있지만 먼저 서버를 업그레이드할 필요는 없습니다. 다른 버전을 사용하는 서버와 클라이언트 간의 통신은 인터럽트되지 않습니다. 그러나 클라이언트와 서버가 모두 업그레이드될 때까지 보안 향상의 이점을 얻을 수 없습니다.

SESSIONSECURITY 매개변수를 사용하여 엄격한 보안 적용
새 보안 프로토콜을 사용하려면 서버, 클라이언트 노드 또는 관리자 엔티티가 SESSIONSECURITY 매개변수를 지원하는 IBM Storage Protect 소프트웨어를 사용해야 합니다. 세션 보안은 IBM Storage Protect 클라이언트 노드, 관리 클라이언트 및 서버 간의 통신에 사용되는 보안 레벨입니다. 이 매개변수에 대해 다음 값을 지정할 수 있습니다.
엄격
서버, 노드 및 IBM Storage Protect 관리자 간의 통신에 대해 최고 수준의 보안을 적용하며, 현재 적용되는 프로토콜은 TLS 1.2 입니다.
Transitional
소프트웨어를 IBM Storage Protect V8.1.2 이상으로 업데이트할 때까지 기존 통신 프로토콜(예: TCP/IP )이 사용됨을 나타냅니다. 이는 기본값입니다. TLS 프로토콜의 상위 버전이 사용되거나 소프트웨어가 V8.1.2 이상으로 업데이트되면 SESSIONSECURITY=TRANSITIONAL, 더 엄격한 보안 설정이 자동으로 적용됩니다. 노드, 관리자 또는 서버가 STRICT 값에 대한 요구 사항을 충족하면 세션 보안 수준이 자동으로 STRICT 값으로 업데이트되며, 해당 엔터티는 이전 버전의 클라이언트나 이전 버전의 TLS 프로토콜을 사용하여 더 이상 인증할 수 없게 됩니다.
SESSIONSECURITY=TRANSITIONAL 및 서버, 노드 또는 관리자가 STRICT값에 대한 요구사항을 충족하지 않은 경우 서버, 노드 또는 관리자는 TRANSIAL값을 사용하여 계속 인증합니다. 그러나 서버, 노드 또는 관리자가 STRICT값에 대한 요구사항을 충족하면 SESSIONSECURITY 매개변수 값이 자동으로 TRANSIAL에서 STRUCT로 업데이트됩니다. 그러면 서버, 노드 또는 관리자는 STRICT 요구 사항을 충족하지 않는 클라이언트 버전이나 SSL / TLS 프로토콜을 사용하여 더 이상 인증할 수 없게 됩니다.
제한사항: 관리자가 IBM Storage Protect V8.1.2 이상 소프트웨어 또는 Tivoli Storage Manager V7.1.8 이상 소프트웨어를 사용하여 서버에 대해 인증한 후에는 관리자가 V8.1.2 또는 V7.1.8이전의 클라이언트 또는 서버 버전을 사용하여 더 이상 동일한 서버에 대해 인증할 수 없습니다. 이 제한사항은 명령 라우팅, 대상 IBM Storage Protect 서버를 다른 서버의 관리자로 인증하는 서버 대 서버 내보내기, Operations Center를 사용하는 관리자 연결 및 관리 명령행 클라이언트의 연결과 같은 기능을 사용하는 경우에도 대상 서버에 적용됩니다.
클라이언트 및 관리 세션의 경우, 관리자 ID가 연결할 모든 서버에 대한 인증서를 이미 획득하지 않은 경우 관리 명령 라우팅 세션이 실패할 수 있습니다. dsmadmc 명령, dsmc 명령 또는 dsm 프로그램을 사용하여 인증하는 관리자는 V8.1.2 이상을 사용하여 인증한 후 이전 버전을 사용하여 인증할 수 없습니다. 관리자의 인증 문제를 해결하려면 다음 팁을 참조하십시오.
  • 관리자 계정이 로그온하는 데 사용하는 모든 IBM Storage Protect 소프트웨어가 V8.1.2 이상으로 업그레이드되었는지 확인하십시오. 관리자 계정이 여러 시스템에서 로그온하는 경우, 서버의 인증서가 각 시스템에 설치되어 있는지 확인하십시오.
  • 필요한 경우, V8.1.1 또는 이전 소프트웨어를 사용하는 클라이언트 및 서버에서만 사용할 별도의 관리자 계정을 작성하십시오.

업그레이드하기 전에

서버를 업그레이드하기 전에 다음 체크리스트의 가이드라인을 검토하십시오.
표 1. 계획 체크리스트
지침 설명
다음 서버 파일을 백업하십시오.
  • 키 데이터베이스 (cert.kdb 및 dsmkeydb.kdb)
  • 스태쉬 파일 (cert.sth 및 dsmkeydb.sth)

IBM Storage Protect 버전 8.1.2부터 마스터 암호화 키가 이전에 존재하지 않은 경우 서버를 시작할 때 마스터 암호화 키가 자동으로 생성됩니다.

마스터 암호화 키는 키 데이터베이스 dsmkeydb.kdb에 저장됩니다. 서버 인증서는 cert.kdb 키 데이터베이스에 저장되어 있으며 스태쉬 파일 cert.sth에 의해 액세스됩니다. 각 키 데이터베이스에 대한 액세스를 제공하는 키 데이터베이스 (cert.kdb 및 dsmkeydb.kdb) 및 스태쉬 파일 (cert.sth 및 dsmkeydb.sth) 을 모두 보호해야 합니다. 기본적으로 BACKUP DB 명령은 볼륨 히스토리 및 devconfig 파일이 보호되는 것과 동일한 방식으로 마스터 암호화 키를 보호합니다. 데이터베이스를 복원하려면 데이터베이스 백업 비밀번호를 기억해야 합니다. 이전 릴리스에서 마스터 암호화 키를 저장하는 데 사용된 IBM Storage Protect server dsmserv.pwd 파일은 더 이상 사용되지 않습니다.
관리자 ID의 업그레이드를 신중하게 계획하십시오. 관리자 계정이 관리 목적으로 로그인하는 데 사용하는 모든 시스템을 식별하십시오.
V8.1.2 이상 소프트웨어에 대한 인증이 성공하면 관리자가 동일한 서버에서 IBM Storage Protect 소프트웨어의 이전 버전에 대해 인증할 수 없습니다. 단일 관리자 ID를 사용하여 여러 시스템에 로그인하는 경우, V8.1.2 이상 소프트웨어를 사용하여 모든 해당 시스템을 업그레이드하도록 계획하여 관리자가 로그인하는 모든 시스템에 인증서가 설치되도록 하십시오.
팁: 모든 관리자 ID의 SESSIONSECURITY 매개변수가 STRICT값으로 업데이트되는 경우 서버가 잠기지 않습니다. dsmadmc 명령을 실행하는 클라이언트에 서버의 공용 인증서를 수동으로 가져올 수 있습니다.
TSM Server SelfSigned Key ( cert.arm ) 인증서를 사용하는 이전 버전의 클라이언트와 함께 TLS 를 사용 중인 경우, 클라이언트를 V8.1.4 이상으로 업데이트하십시오. V7.1.8 이전 버전에서는 기본 인증 서의 이름이 ‘TSM Server SelfSigned Key’였으며, MD5 서명을 사용했습니다. 이 서명은 V8.1.2 이상 클라이언트 및 Operations Center에서 기본적으로 요구하는 TLS 1.2 이상 프로토콜을 지원하지 않습니다. 이 문제를 해결하려면 다음 단계 중 하나를 완료하십시오.
  • 서버를 V8.1.4 이상으로 업그레이드하십시오. V8.1.4부터 MD5-signed 인증서를 기본값으로 사용하는 서버는 TSM Server SelfSigned SHA Key로 레이블 지정된 SHA 서명이 있는 기본 인증서를 사용하도록 자동으로 업데이트됩니다. 새 기본 인증서의 사본은 서버 인스턴스 디렉토리에 있는 cert256.arm 파일에 저장됩니다.
    팁: SHA 서명이 있는 새 기본 인증서를 사용하도록 서버를 업데이트하기 전에 클라이언트 백업 실패를 방지하도록 cert256.arm 파일을 클라이언트에 분배하십시오. 각 클라이언트는 새 기본 SHA 인증서를 사용하는 서버에 연결하기 전에 새 인증서를 확보하여 가져와야 합니다. 이전 인증서를 제거할 필요가 없습니다.
  • 기본 인증서를 수동으로 업데이트하려면 기술 노트 562939의 지시사항을 따르십시오.

다음에 수행할 작업